Re: [Gnucap-devel] CMake

[al davis]

On Fri, 10 Feb 2017 21:26:31 +0100
Guilherme Brondani Torri <address@hidden> wrote:
> I also had to create a /usr/local/bin/gnucap.rc containing:
> "load /usr/local/lib/gnucap/gnucap-default-plugins.dylib"

That's one way to do it.

> 
> For some reason it would not find the plugins:
> ===
> main version: unstable 2016.11.17
> core-lib version: unstable 2016.11.17
> load gnucap-default-plugins.dylib
>      ^ ? dlopen(gnucap-default-plugins.dylib, 6): image not found
> libc++abi.dylib: terminating with uncaught exception of type Exception_CS
> Abort trap: 6
> ===

Finding the plugins in a portable or automatically configurable way has
been a problem.  I have not found a way that I am completely satisfied
with.  If you have any ideas, please let me know.

The various "plugpath" branches are attempts at some ways to deal with
this.  "plugpath", "plugpath+" add compiler options to set tags in the
files.  I could not make this work the way I think it should, and it
only addresses one platform.  "plugpath-2" and followups bypass the
default search and explicitly specify it.  I think this could be
better, but doesn't work if whatever way to explicitly specify is
missing.  This should be easy to fix, so I am leaning toward this way,
but it still needs work.


Some issues .....

The file suffix .. .so , .dylib, .dll ....  others?  Aside from just
the name match, having different suffix makes for an inconsistent
user experience.  The names are different on different systems.  Should
we make up a new suffix that is the same on all systems?

dlopen search strategy seems to be different on different systems, and
doesn't work the way the docs imply it should.

The default search path sometimes requires the file
name to begin with "lib".  Originally, the default plugin collection
file was "libgnucap-default-plugins.so", but we dropped the "lib"
because it is intended to be loaded with dlopen, not automatically
linked at startup.  Actually, if it is renamed back to add the "lib"
prefix, it can be linked at startup or static linked.  A problem
finding the file was introduced when we removed the "lib".  Should we
put it back?

This is initially an issue with the default plugins, but really also an
issue with plugins loaded by the user, or by gnucap.rc.

Should the load command syntax just specify the base name, then let
the software add a system dependent prefix and suffix to make the
default search happy?

> So, CMake is working for me.
> 
> So far I haven't tried the Make1, Make2, Make3 makefiles.

That's what I use.  It's really just a plain Makefile in 3 parts.
Make1 is specific to this program and not tied to the platform.  Make2
configures to the platform, this computer.  Make3 is boiler-plate, the
same everywhere.  
The real Makefile is made by "cat Make1 Make2 Make3 >Makefile".

Make2.xxxx are pre-configured versions of Make2, which can be used as
alternatives without running ./configure when you want something
specific.

./configure generates Make2.

I find it a lot easier to work with than any of the automated
configuration tools, but it doesn't have all of the options that some
claim they need.  To provide that would be just more stuff in Make3,
but I haven't done it, wishfully hoping for one of the config tools to
do what it is supposed to do in a clean modular way that does not get
in the way.

I would like to be able to think of configuration as like plugins, but
it doesn't quite work that way.

> I also tried fixing the autotools build, see [2] (which is now based on
> [1]).
> It builds fine but I am unable to run it. See bellow:
> 
> >From the build directory:  
> ===
> [autotools-osx]~/git/gnucap $ ./main/gnucap
> ./main/gnucap.real: line 117:
> /Users/guitorri/git/gnucap/main/.libs/gnucap.real: cannot execute binary
> file
> ./main/gnucap.real: line 117:
> /Users/guitorri/git/gnucap/main/.libs/gnucap.real: Undefined error: 0
> ===
> 
> After make install:
> ===
> [autotools-osx]~/git/gnucap $ gnucap
> -bash: /usr/local/bin/gnucap: cannot execute binary file
> [autotools-osx]~/git/gnucap $ which gnucap
> /usr/local/bin/gnucap
> [autotools-osx]~/git/gnucap $ otool -L /usr/local/bin/gnucap
> /usr/local/bin/gnucap:
> .libs/gnucap.real (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/lib/libgnucap.0.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1238.0.0)
> /usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version
> 3.0.0)
> /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version
> 5.4.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 307.4.0)
> ===
> 
> How to proceed to get the functioning patches upstream?
> Shall I split the patches targeting unstable, cmake and autotools branches?

What the branches are ....

"master" is considered stable.  A tag represents a release.  It is only
changed by pushing unstable to master.

"unstable" is the active development branch, but is not changed
directly.  Changes are done by merging topic branches when they are
ready, always brought up for review on gnucap-devel before doing the
merge.

Other (topic) branches are where work is done.  To be considered for
merge, it must have the current unstable as an ancestor, so as to
qualify for a "fast-forward" merge, but we actually merge with "no-ff"
for logging.