[Asterisk-code-review] RFC: build-system: Build with static pjproject as the default (asterisk[13])

[George Joseph]

Hello Anonymous Coward #1000019,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/2072

to look at the new patch set (#2).

Change subject: RFC: build-system: Build with static pjproject as the default
......................................................................

RFC: build-system: Build with static pjproject as the default

Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html

The new default behavior is to link Asterisk statically against a local
instance located in third_party/pjproject.  The original behavior of
linking to the shared libraries of the system-installed pjproject can
be restored with a ./configure option.

Building:

New ./configure options:

--with-pjproject-shared=PATH
	Dynamically link to the shared libraries in PATH (or the system
	default).  This is the equivalent of the old --with-pjproject option
	(but it must now be explicitly specified).
--with-pjproject-static=PATH
	Statically link to the .a archive files located in a pjproject source
	directory.  PATH defaults to ./third_party/pjproject/source.
	pjproject must already have been built WITHOUT the --enable-shared
	option and a build.mak file must be available in that directory.

The default is --with-pjproject-static.  You can disable pjproject
altogether with --without-pjproject-static

To build, cd to third_party/pjproject and type 'make'.  The Makefile will
download an official tarball from pjsip.org, unpack it into the 'source'
subdirectory, apply any patches located in the 'patches' directory, run
configure with the correct options, do a 'make dep' and a 'make'.

When that's done, cd to the Asterisk top directory, run './configure' with
your favorite options and proceed as normal.

Use the --with-pjproject-shared to restore the old behavior.  You should
run 'make distclean' when changing between the shared and static
implementations.

Implementation Notes:

*****
When running the static version, you must add a 'preload = res_pjproject.so'
line to modules.conf.  I have yet to figure out a sure-fire way to force a
module to load early from code.  Suggestions welcomed.
*****

No c source files were changed.

res_pjsip.h was modified so that CHECK_PJSIP_MODULE_LOADED also checks for
res_pjproject if the HAVE_PJPROJECT_STATIC flag is set.

AST_EXT_LIB_SETUP was modified to explicitly set USE_$1 to 'yes' or
'notspecified' to facilitate positive determination of whether an option
was specified or not.  Two new arguments were also added, one to allow a
code block to be executed if the option was not specified, and another to
specify a 'cabability' to add to ac_mandatory_list instead of the package
name.  PJPROJECT_SHARED and PJPROJECT_STATIC both set PJPROJECT for
instance.  Either satisfies the capability but only one can be specified.

configure.ac was modified to process the new options and perform appropriate
checks.

res_pjproject now houses all pjproject APIs so res/Makefile was modified
to perform special processing on res_pjproject if using the static
libraries.

The res_pjproject.exports file is now dynamically built by listing the
global symbols from pjproject's .a files.  Since the original export
generation commands were embedded in the '%.so: %.o' rules, it wasn't
possible to override them just for res_pjproject.  Instead, the exports
files have been given their own rules ('%.exports: %.exports.in') which
allows them to be overridden with a
'res_pjproject.exports: res_pjproject.exports.in' rule that combines the
existing res_pjproject.exports.in file with the symbols from pjproject.

A side effect of the new catch-all exports rule is that they now echo
messages to the terminal.
If there was no specific .in file for a module...
   [COPY]  default.exports.in -> <module>.exports
otherwise...
   [GENERATE]  <module>.exports.in -> <module>.exports
I can squash them if they're too noisy.

Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  They should only
depend on res_pjproject if they need a specific res_pjproject API.

I would like to alter the dependency chain if HAVE_JPROJECT_STATIC is
specified so menuselect shows that res_pjproject is needed but so far
that has eluded me as well.

REMINDER:  This is an RFC only at this time.

Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
---
M Makefile.rules
M autoconf/ast_ext_lib.m4
M build_tools/make_linker_version_script
M configure
M configure.ac
R default.exports.in
M include/asterisk/autoconfig.h.in
M include/asterisk/res_pjsip.h
M makeopts.in
M res/Makefile
A third_party/Makefile
A third_party/pjproject/.gitignore
A third_party/pjproject/Makefile
A third_party/pjproject/apply_patches
A third_party/pjproject/patches/0002-no_third_party.patch
15 files changed, 1,330 insertions(+), 220 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/72/2072/2
-- 
To view, visit https://gerrit.asterisk.org/2072
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Owner: George Joseph <george.joseph at fairview5.com>
Gerrit-Reviewer: Anonymous Coward #1000019