Re: cmake branch

Hello,

On Thu, Oct 19, 2017 at 5:14 PM, al davis <[email protected]> wrote:

> "cmake-2" is a rebase of cmake-1.
>
> Quick test .. I see one problem, and don't know cmake enough to fix ..
>

I see a few other problems. Parts of main/config.h.in are new. CMake does
not know yet how to configure it.
I am looking into it.


> The default plugins are installed as "libgnucap-default-plugins.so",
> which isn't found by gnucap.  Apparently, cmake prepends "lib" even if
> we don't ask for it.  The convention used  here is that plugins do not
> have the lib prefix because of the intent to load with dlopen, not at
> link time.
>

This should work:
set_target_properties(gnucap-default-plugins  PROPERTIES OUTPUT_NAME
"gnucap-default-plugin")
or:
set_target_properties(gnucap-default-plugins  PROPERTIES PREFIX "")


> Sometimes I wonder if that is a good decision.  With a "lib" prefix, it
> could be linked at startup or at link time (static link), which would
> enable gnucap to run on systems with messed up support for dynamic
> libraries.  The design of plugins is such that they can be loaded
> either way.
>

Whatever works. I've seen at least another project Linux-PAM which drops
the lib prefix for loadable modules.


> So (especially addressed to Guilherme and Kevin, who know cmake) ..
> can you fix this?
>

I looking for the fixes.

In the mean time, I patched the autotools branch to fix the compilation on
OSX, see last commit in [1].

I have access to Savannah. How should I proceed?
In the above case I guess the patch should go first into develop and them
merged into autotools?
Shall I branch from develop add my patches and push new branches to the
remote for you to merge?
Please advise.

Best regards,
Guilherme

[1] https://github.com/guitorri/gnucap/commits/autotools-fix-osx