Binary distributability of codeblocks: GPL & OpenSSL conflict

[Mojca Miklavec]

[waking the thread from the dead]

On Fri, Jul 11, 2014 at 12:14 AM, Joshua Root wrote:
> On 2014-7-11 04:52 , Mojca Miklavec wrote:
>> Hi,
>>
>> I would like to ask if there is any chance to make Code::Blocks
>> distributable and what would have to be done.
>>
>>> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base/portmgr/jobs/port_binary_distributable.tcl -v codeblocks
>>
>> "codeblocks" is not distributable because its license "gpl" conflicts
>> with license "OpenSSL" of dependency "openssl"
>>
>> Codeblocks depends on boost which further depends on openssl.
>
> Not quite, boost depends on python27 which depends on openssl.
>
> Check if codeblocks is linked against the boost libs that use python,
> and also check if the boost python libs use any of python's SSL-using
> modules. If not, you can add 'license_noconflict boost' to codeblocks.

I'm probably blind, but I'm unable to find *any* library that would
even link against boost.

The headers are used in NassiShneiderman, but
    otool -L /opt/local/lib/codeblocks/plugins/libNassiShneiderman.so
doesn't shouw any link against boost. I also don't see anything trying
to link against boost in Makefiles.

Just
    if test "x$BUILD_NASSISHNEIDERMAN_TRUE" = "x" ; then
      AC_LANG_PUSH([C++])
        AC_CHECK_HEADER([boost/spirit/include/classic.hpp],[],[AC_MSG_ERROR([...])])
      AC_LANG_POP([C++])
    fi

I'll add 'license_noconflict boost' like you suggested.

(The build is broken on 10.9 and later, but I have no clue how to fix it.)

>> A while ago it was apparently distributable – or at least one file
>> exists in http://packages.macports.org/codeblocks/
>
> That was before the boost dependency was added.
>
> - Josh

Thank you,
    Mojca