3 Commits (e3de4bc46e0332050f3fd296202abe94d13c20a5)

Author	SHA1	Message	Date
Richard Mudgett	30cb4eb57f	PJPROJECT logging: Fix detection of max supported log level. ... The mechanism used for detecting the maximum log level compiled into the linked pjproject did not work. The API call simply stores the requested level into an integer and does no range checking. Asterisk was assuming that there was range checking and limited the new value to the allowable range. To get the actual maximum log level compiled into the linked pjproject we need to get and save off the initial set log level from pjproject. This is the maximum log level supported. * Get and save off the initial log level setting before altering it to the desired level on startup. This has to be done by a macro rather than calling a core function to avoid incorrectly linking pjproject. * Split the initial log level warning messages to warn if the linked pjproject cannot support the requested startup level and if it is too low to get the pjproject buildopts for "pjproject show buildopts". * Adjust the CLI "pjproject set log level" to check the saved max log level and to generate normal output messages instead of a warning message. ASTERISK-26743 #close Change-Id: I40aa76653e2a1dece66c3f8734594b4f0471cfb4	8 years ago
Richard Mudgett	44fe4a5769	PJPROJECT logging: Made easier to get available logging levels. ... Use of the new logging is as simple as issuing the new CLI command or setting the new pjproject.conf option. Other options that can affect the logging are how you have the pjproject log levels mapped to Asterisk log types in pjproject.conf and if you have configured Asterisk to log the DEBUG type messages. Altering the pjproject.conf level mapping shouldn't be necessary for most installations as the default mapping is sensible. Configuring Asterisk to log the DEBUG message type is standard practice for collecting debug information. * Added CLI "pjproject set log level" command to dynamically adjust the maximum pjproject log message level. * Added CLI "pjproject show log level" command to see the currently set maximum pjproject log message level. * Added pjproject.conf startup section "log_level" option to set the initial maximum pjproject log message level so all messages could be captured from initialization. * Set PJ_LOG_MAX_LEVEL to 6 to compile in all defined logging levels into bundled pjproject. Pjproject will use the currently set run time log level to determine if a log message is generated just like Asterisk verbose and debug logging levels. * In log_forwarder(), made always log enabled and mapped pjproject log messages. DEBUG mapped log messages are no longer gated by the current Asterisk debug logging level. * Removed RAII_VAR() from res_pjproject.c:get_log_level(). ASTERISK-26630 #close Change-Id: I6dca12979f482ffb0450aaf58db0fe0f6d2e5389	9 years ago
George Joseph	b59956a875	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	9 years ago