[asterisk-bugs] [JIRA] (ASTERISK-28929) pjproject_bundled: Honor --without-pjproject.

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251050#comment-251050 ] 

Friendly Automation commented on ASTERISK-28929:
------------------------------------------------

Change 14479 merged by Friendly Automation:
pjproject_bundled: Honor --without-pjproject.

[https://gerrit.asterisk.org/c/asterisk/+/14479|https://gerrit.asterisk.org/c/asterisk/+/14479]

> pjproject_bundled: Honor --without-pjproject.
> ---------------------------------------------
>
>                 Key: ASTERISK-28929
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28929
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/BuildSystem, pjproject/pjsip
>    Affects Versions: 16.10.0, 17.4.0
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>              Labels: patch
>         Attachments: without_pjproject.patch
>
>
> Fixing my own stuff. ASTERISK-28837 is incomplete, the change creates a new issue, and its issue description is wrong actually.
> *First*, the wrong issue description:
> bq. {{./configure --without-pjproject --without-pjproject-bundled}} … errors
> No. I did not test but just read the error message in the file {{third-party/pjproject/configure.m4}}. The code there is different: Only with
> bq. {{./configure --with-pjproject --with-pjproject-bundled}}
> the script {{./configure}} should error. Should, because the check is wrong because {{--with-pjproject}} is not parsed yet—when that test is executed: {{THIRD_PARTY_CONFIGURE()}} is called before {{AST_EXT_LIB_SETUP(\[PJPROJECT\] …)}}.
> *Second*, the new issue:
> bq. {{./configure --without-pjproject --without-pjproject-bundled}}
> gives
> {noformat}
>    [CC] libasteriskpj.c -> libasteriskpj.o
> make[1]: *** No rule to make target 'pjproject.symbols', needed by 'libasteriskpj.exports'.  Stop.
> make: *** [Makefile:387: main] Error 2
> {noformat}because the Makefile still looks for the state of the variable {{PJPROJECT_BUNDLED}} (several times). After the change for ASTERISK-28837, the script {{./configure}} does not download the PJProject. Yehh. However, {{make}} downloads the PJProject. And because of the change for ASTERISK-28837, several build variables are not set, {{make}} enters an unexpected state.
> *Third*, the incomplete part:
> As mentioned already, not only the script {{./configure}} but also {{make}} downloads the PJProject if it was removed why ever.
> *Therefore*,
> bq. {{./configure --without-pjproject --without-pjproject-bundled}}
> worked before ASTERISK-28837. Only
> bq. {{./configure --without-pjproject}}
> did not disable the PJProject also. Consequently, ASTERISK-28837 was not a major but just a minor issue because a workaround existed. ASTERISK-28837 was about a difference between Asterisk 13 and newer branches. In newer branches {{--without-pjproject}} is not enough to disable PJProject, you have to disable the bundled PJProject as well. That is couter-intuitive. Therefore ASTERISK-28837 was valid but the analysis and its change was wrong.
> Just noticed this while testing the latest Asterisk branch. Normally, I am on Asterisk 13 and there {{PJPROJECT_BUNDLED=no}} on default and therefore I did not notice that {{make}} issue. Puh. Sorry.



--
This message was sent by Atlassian JIRA
(v6.2#6252)