Now that the warnings in osmo-iuh have been fixed, we should be able to
build the IU version of OsmoSGSN with --enable-werror too.
Related: OS#4462
Change-Id: I8cc4e209e21acfe513bef72927499f1ccdead783
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: Ic45322c809f9f65d0fd24b828dab0cd929fa6267
osmo-hlr has recently (as of Change-Id
Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library
implementation of libosmo-gsup-client.
We can remove the local implementation in osmo-sgsn and use the
system-installed shared library instead.
Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
The flag cannot be enabled in all cases because current osmo-iuh header
contain compilation warnings which are then propagated to this project
when building against them.
Change-Id: Ia4285a88af6d4adfba08c055c6734f9d82c1a5a4
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I7c3ecd83899f873bdc771ff7445740fea15900ef
The bug fixed by Idb034bf2ae749204836ab7e02018d769bb242a9f was not
detected by jenkins because it installs libosmo-sccp unconditionally.
Let's be more strict and install it only when necessary for IU builds to
make sure we can catch such bugs in future.
Change-Id: I573c7fec687edb71d79815b38a3bcf96273c03b3
Rewire build and includes to libosmo-legacy-mgcp.
Drop osmo-bsc_mgcp and related python tests, now found in osmo-mgw.git.
libosmo-legacy-mgcp is installed from osmo-mgw, hence add the dependency to
jenkins.sh (so far using the pre_release branch).
Change-Id: Ic99d681759edce11564da62500c2aac5cf5fffe2
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
Necessary since libosmocore I513835be2d931d0a931cdfc996f361a451bc1a15
removes the script from libosmocore/contrib.
Change-Id: I02d7e1c0151c687fd9341d21a09ca15cbf5a1938
Enable various components according to the build matrix during make distcheck.
Add python tests, osmo-bsc, nat, ...
Change-Id: Ic724cf61d44409337414dc58c8795896b4b97a8a
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
We are building with libosmo-sccp tag 'old_sua' until the new sigtran has
been applied. Since osmo-iuh commit
0f88c110093935305143987638e46dc6db304a3e
"migrate osmo-hnbgw to libosmo-sigtran's SCCP/M3UA"
osmo-iuh requires libosmo-sccp master. A similar 'old_sua' tag is in place in
osmo-iuh.git, to match libosmo-sccp 'old_sua'. Do that to fix the jenkins
build of --enable-iu.
Change-Id: I70f731db0b74ed48ae6dd713ed4c3247222ef0de
Have a bash function to build each dependency with the same commands. There is
a tradeoff: having each dependency build with the same function means you can't
easily tweak one of the dependencies. OTOH having a unified function means a)
more readable script, b) that we're sure not to forget some steps and c) no
need to do the same edit n times.
Set the PKG_CONFIG_PATH globally. Also a tradeoff: if a future addition
wouldn't need the same PKG_CONFIG_PATH, this would make things ugly. But that
is actually quite unlikely, and the readability improvement is substantial.
Use env variables to remember local paths. That means we always are sure to cd
to the same absolute base path, which a 'cd ..' can't guarantee; also, we avoid
possible typos for e.g. "$deps/install".
Change-Id: Ib23f86c6cc1441d882de59bcdde5de87fa4e9fdf
Oliver Smith
Pau Espin
Harald Welte
Max
Neels Hofmeyr
Philipp Maier