| 
									
										
										
										
											2017-06-30 07:31:52 -06:00
										 |  |  | # | 
					
						
							|  |  |  | # If this file is changed, be sure to run ASTTOPDIR/bootstrap.sh | 
					
						
							|  |  |  | # before committing. | 
					
						
							|  |  |  | # | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-10-03 10:30:43 -06:00
										 |  |  | AC_DEFUN([_PJPROJECT_CONFIGURE], | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | [ | 
					
						
							| 
									
										
										
										
											2016-10-03 10:30:43 -06:00
										 |  |  | 	if test "${ac_mandatory_list#*PJPROJECT*}" != "$ac_mandatory_list" ; then | 
					
						
							|  |  |  | 		AC_MSG_ERROR(--with-pjproject and --with-pjproject-bundled can't both be specified) | 
					
						
							|  |  |  | 	fi | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 	if test "${with_pjproject}" != "no" && test "${with_pjproject}" != "n" ; then | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		ac_mandatory_list="$ac_mandatory_list PJPROJECT" | 
					
						
							|  |  |  | 		PJPROJECT_DIR="${ac_top_build_prefix}third-party/pjproject" | 
					
						
							| 
									
										
										
										
											2016-10-14 01:18:50 -04:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_MSG_CHECKING(for embedded pjproject (may have to download)) | 
					
						
							|  |  |  | 		AC_MSG_RESULT(configuring) | 
					
						
							| 
									
										
										
										
											2016-10-14 01:18:50 -04:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		if test "x${DOWNLOAD_TO_STDOUT}" = "x" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(A download utility (wget, curl, or fetch) is required to download bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${BZIP2}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(bzip2 is required to extract the pjproject tar file) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${TAR}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(tar is required to extract the pjproject tar file) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${PATCH}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(patch is required to configure bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${SED}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(sed is required to configure bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${NM}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(nm is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${MD5}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(md5sum is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${CAT}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(cat is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${CUT}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(cut is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "${GREP}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(grep is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							| 
									
										
										
										
											2021-11-30 15:35:27 -07:00
										 |  |  | 		if test "${FIND}" = ":" ; then | 
					
						
							|  |  |  | 			AC_MSG_ERROR(find is required to build bundled pjproject) | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 		if test "x${AST_DEVMODE}" != "x" ; then | 
					
						
							|  |  |  | 			if test "${REALPATH}" = ":" ; then | 
					
						
							|  |  |  | 				AC_MSG_ERROR(realpath is required to build bundled pjproject in dev mode) | 
					
						
							|  |  |  | 			fi | 
					
						
							|  |  |  | 		fi | 
					
						
							| 
									
										
										
										
											2017-06-30 07:31:52 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_ARG_VAR([PJPROJECT_CONFIGURE_OPTS],[Additional configure options to pass to bundled pjproject]) | 
					
						
							|  |  |  | 		this_host=$(./config.sub $(./config.guess)) | 
					
						
							|  |  |  | 		if test "$build" != "$this_host" ; then | 
					
						
							| 
									
										
										
										
											2020-05-03 12:30:15 +02:00
										 |  |  | 			PJPROJECT_CONFIGURE_OPTS="${PJPROJECT_CONFIGURE_OPTS} --build=$build_alias" | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		fi | 
					
						
							|  |  |  | 		if test "$host" != "$this_host" ; then | 
					
						
							| 
									
										
										
										
											2020-05-03 12:30:15 +02:00
										 |  |  | 			PJPROJECT_CONFIGURE_OPTS="${PJPROJECT_CONFIGURE_OPTS} --host=$host_alias" | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		fi | 
					
						
							|  |  |  | 		# This was a copy of the autoconf generated code from the root ./configure. | 
					
						
							|  |  |  | 		# Hopefully, when you read this, the code is still the same. | 
					
						
							|  |  |  | 		if test "${with_ssl+set}" = set; then : | 
					
						
							|  |  |  | 			case $with_ssl in | 
					
						
							|  |  |  | 			n|no) | 
					
						
							| 
									
										
										
										
											2020-05-03 12:30:15 +02:00
										 |  |  | 			PJPROJECT_CONFIGURE_OPTS="${PJPROJECT_CONFIGURE_OPTS} --disable-ssl" | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 			;; | 
					
						
							|  |  |  | 			y|ye|yes) | 
					
						
							|  |  |  | 			# Not to mention SSL is the default in PJProject and means "autodetect". | 
					
						
							|  |  |  | 			# In Asterisk, "./configure --with-ssl" means "must be present". | 
					
						
							| 
									
										
										
										
											2020-05-03 12:30:15 +02:00
										 |  |  | 			PJPROJECT_CONFIGURE_OPTS="${PJPROJECT_CONFIGURE_OPTS}" | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 			;; | 
					
						
							|  |  |  | 			*) | 
					
						
							| 
									
										
										
										
											2020-05-03 12:30:15 +02:00
										 |  |  | 			PJPROJECT_CONFIGURE_OPTS="${PJPROJECT_CONFIGURE_OPTS} --with-ssl=${with_ssl}" | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 			;; | 
					
						
							|  |  |  | 			esac | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2021-11-30 15:35:27 -07:00
										 |  |  | 		# Determine if we're doing an out-of-tree build... | 
					
						
							|  |  |  | 		AH_TEMPLATE(m4_bpatsubst([[HAVE_PJPROJECT_BUNDLED_OOT]], [(.*)]), [Define if doing a bundled pjproject out-of-tree build.]) | 
					
						
							|  |  |  | 		if test -L ${PJPROJECT_DIR}/source -o -d ${PJPROJECT_DIR}/source/.git ; then | 
					
						
							|  |  |  | 			AC_DEFINE([HAVE_PJPROJECT_BUNDLED_OOT], 1) | 
					
						
							|  |  |  | 			PJPROJECT_BUNDLED_OOT=yes | 
					
						
							|  |  |  | 		fi | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 		export TAR PATCH SED NM EXTERNALS_CACHE_DIR AST_DOWNLOAD_CACHE DOWNLOAD_TO_STDOUT DOWNLOAD_TIMEOUT DOWNLOAD MD5 CAT CUT GREP FIND REALPATH | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		export NOISY_BUILD AST_DEVMODE | 
					
						
							|  |  |  | 		${GNU_MAKE} --quiet --no-print-directory -C ${PJPROJECT_DIR} \ | 
					
						
							|  |  |  | 			PJPROJECT_CONFIGURE_OPTS="$PJPROJECT_CONFIGURE_OPTS" \ | 
					
						
							|  |  |  | 			EXTERNALS_CACHE_DIR="${EXTERNALS_CACHE_DIR:-${AST_DOWNLOAD_CACHE}}" \ | 
					
						
							| 
									
										
										
										
											2021-11-30 15:35:27 -07:00
										 |  |  | 			PJPROJECT_BUNDLED_OOT="${PJPROJECT_BUNDLED_OOT}" \ | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 			configure | 
					
						
							|  |  |  | 		if test $? -ne 0 ; then | 
					
						
							|  |  |  | 			AC_MSG_RESULT(failed) | 
					
						
							|  |  |  | 			AC_MSG_NOTICE(Unable to configure ${PJPROJECT_DIR}) | 
					
						
							|  |  |  | 			AC_MSG_ERROR(Re-run the ./configure command with 'NOISY_BUILD=yes' appended to see error details.) | 
					
						
							|  |  |  | 		fi | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_MSG_CHECKING(for bundled pjproject) | 
					
						
							| 
									
										
										
										
											2016-10-03 10:30:43 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2021-11-30 15:35:27 -07:00
										 |  |  | 		PJPROJECT_INCLUDE=$(${GNU_MAKE} --quiet --no-print-directory -C ${PJPROJECT_DIR} \ | 
					
						
							|  |  |  | 			PJPROJECT_CONFIGURE_OPTS="$PJPROJECT_CONFIGURE_OPTS" \ | 
					
						
							|  |  |  | 			EXTERNALS_CACHE_DIR="${EXTERNALS_CACHE_DIR:-${AST_DOWNLOAD_CACHE}}" \ | 
					
						
							|  |  |  | 			PJPROJECT_BUNDLED_OOT="${PJPROJECT_BUNDLED_OOT}" \ | 
					
						
							|  |  |  | 			echo_cflags) | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		PJPROJECT_CFLAGS="$PJPROJECT_INCLUDE" | 
					
						
							|  |  |  | 		PBX_PJPROJECT=1 | 
					
						
							| 
									
										
										
										
											2016-10-14 01:18:50 -04:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_DEFINE([HAVE_PJPROJECT], 1, [Define if your system has PJPROJECT]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJPROJECT_BUNDLED], 1, [Define if your system has PJPROJECT_BUNDLED]) | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_DEFINE([HAVE_PJSIP_DLG_CREATE_UAS_AND_INC_LOCK], 1, [Define if your system has pjsip_dlg_create_uas_and_inc_lock declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJ_TRANSACTION_GRP_LOCK], 1, [Define if your system has pjsip_tsx_create_uac2 declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_REPLACE_MEDIA_STREAM], 1, [Define if your system has PJSIP_REPLACE_MEDIA_STREAM declared]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_GET_DEST_INFO], 1, [Define if your system has pjsip_get_dest_info declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJ_SSL_CERT_LOAD_FROM_FILES2], 1, [Define if your system has pj_ssl_cert_load_from_files2 declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_EXTERNAL_RESOLVER], 1, [Define if your system has pjsip_endpt_set_ext_resolver declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_TLS_TRANSPORT_PROTO], 1, [Define if your system has PJSIP_TLS_TRANSPORT_PROTO]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_EVSUB_GRP_LOCK], 1, [Define if your system has PJSIP_EVSUB_GRP_LOCK]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_INV_SESSION_REF], 1, [Define if your system has PJSIP_INV_SESSION_REF]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_AUTH_CLT_DEINIT], 1, [Define if your system has pjsip_auth_clt_deinit declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_TSX_LAYER_FIND_TSX2], 1, [Define if your system has pjsip_tsx_layer_find_tsx2 declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_INV_ACCEPT_MULTIPLE_SDP_ANSWERS], 1, [Define if your system has HAVE_PJSIP_INV_ACCEPT_MULTIPLE_SDP_ANSWERS declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_ENDPOINT_COMPACT_FORM], 1, [Define if your system has HAVE_PJSIP_ENDPOINT_COMPACT_FORM declared.]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_TRANSPORT_DISABLE_CONNECTION_REUSE], 1, [Define if your system has HAVE_PJSIP_TRANSPORT_DISABLE_CONNECTION_REUSE declared]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJSIP_OAUTH_AUTHENTICATION], 1, [Define if your system has HAVE_PJSIP_OAUTH_AUTHENTICATION declared]) | 
					
						
							|  |  |  | 		AC_DEFINE([HAVE_PJPROJECT_ON_VALID_ICE_PAIR_CALLBACK], 1, [Define if your system has the on_valid_pair pjnath callback.]) | 
					
						
							| 
									
										
										
										
											2022-08-19 10:24:33 -03:00
										 |  |  | 		AC_DEFINE([HAVE_PJSIP_TLS_TRANSPORT_RESTART], 1, [Define if your system has pjsip_tls_transport_restart support.]) | 
					
						
							| 
									
										
										
										
											2016-10-03 10:30:43 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_SUBST([PJPROJECT_BUNDLED]) | 
					
						
							| 
									
										
										
										
											2021-11-30 15:35:27 -07:00
										 |  |  | 		AC_SUBST([PJPROJECT_BUNDLED_OOT]) | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_SUBST([PJPROJECT_DIR]) | 
					
						
							|  |  |  | 		AC_SUBST([PBX_PJPROJECT]) | 
					
						
							|  |  |  | 		AC_SUBST([PJPROJECT_LIB]) | 
					
						
							|  |  |  | 		AC_SUBST([PJPROJECT_INCLUDE]) | 
					
						
							| 
									
										
											  
											
												BuildSystem: Check for alternate openssl packages
OpenSSL is one of those packages that often have alternatives
with later versions.  For instance, CentOS/EL 7 has an
openssl package at version 1.0.2 but there's an openssl11
package from the epel repository that has 1.1.1.  This gets
installed to /usr/include/openssl11 and /usr/lib64/openssl11.
Unfortunately, the existing --with-ssl and --with-crypto
./configure options expect to point to a source tree and
don't work in this situation.  Also unfortunately, the
checks in ./configure don't use pkg-config.
In order to make this work with the existing situation, you'd
have to run...
./configure --with-ssl=/usr/lib64/openssl11 \
    --with-crypto=/usr/lib64/openssl11 \
    CFLAGS=-I/usr/include/openssl11
BUT...  those options don't get passed down to bundled pjproject
so when you run make, you have to include the CFLAGS again
which is a big pain.
Oh...  To make matters worse, although you can specify
PJPROJECT_CONFIGURE_OPTS on the ./configure command line,
they don't get saved so if you do a make clean, which will
force a re-configure of bundled pjproject, those options
don't get used.
So...
* In configure.ac... Since pkg-config is installed by install_prereq
  anyway, we now use it to check for the system openssl >= 1.1.0.
  If that works, great.  If not, we check for the openssl11
  package. If that works, great.  If not, we fall back to just
  checking for any openssl.  If pkg-config isn't installed for some
  reason, or --with-ssl=<dir> or --with-crypto=<dir> were specified
  on the ./configure command line, we fall back to the existing
  logic that uses AST_EXT_LIB_CHECK().
* The whole OpenSSL check process has been moved up before
  THIRD_PARTY_CONFIGURE(), which does the initial pjproject
  bundled configure, is run.  This way the results of the above
  checks, which may result in new include or library directories,
  is included.
* Although not strictly needed for openssl, We now save the value of
  PJPROJECT_CONFIGURE_OPTS in the makeopts file so it can be used
  again if a re-configure is triggered.
ASTERISK-29693
Change-Id: I341ab7603e6b156aa15a66f43675ac5029d5fbde
											
										 
											2021-10-19 10:35:26 -06:00
										 |  |  | 		AC_SUBST([PJPROJECT_CONFIGURE_OPTS]) | 
					
						
							| 
									
										
										
										
											2020-04-15 20:01:58 +02:00
										 |  |  | 		AC_MSG_RESULT(yes) | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	fi | 
					
						
							| 
									
										
										
										
											2016-10-03 10:30:43 -06:00
										 |  |  | ]) | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | AC_DEFUN([PJPROJECT_CONFIGURE], | 
					
						
							|  |  |  | [ | 
					
						
							|  |  |  | 	if test "$PJPROJECT_BUNDLED" = "yes" ; then | 
					
						
							|  |  |  | 		_PJPROJECT_CONFIGURE() | 
					
						
							|  |  |  | 	fi | 
					
						
							| 
									
										
											  
											
												build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.
   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.
   The default behavior remains building with the shared pjproject
   installation, if any.
Building:
   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.
Behind the scenes:
   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.
   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.
   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.
   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.
   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.
   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.
   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.
   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
											
										 
											2016-01-18 20:54:28 -07:00
										 |  |  | ]) |