Re: [Gnucap-devel] libtool?

[al davis]

On Mon, 11 Apr 2016 17:00:29 +0200
Felix Salfelder <address@hidden> wrote:

> - i have no idea, what the cross-platform implications are.

Build systems are all about cross-platform implications

>   and i don't
>   know, how the build system is meant to work,

The old build system is really just a modular Makefile.  The 3 parts
(which don't necessarily need to be 3) ..  Make1 is about this here
project.  Make2 is configuration.  Make3 is boilerplate, generic stuff.

It doesn't need to be 3 parts.  It could be more.  If something is
optional, just add another part for it.  Actually, there are 4 parts.
There's also "Make.depend" which is automatically generated, in a
manner that used to be the way everybody did it, on request, not every
time anything is compiled like autotools does.

The way the existing configure script works is to build the pieces,
then cat them as "Make2".

The other Make2.* are alternatives, for use without configure, when
configure doesn't work.  Originally, that's all there was.

>   hence i tried to add this   *as an option* first.
> - there's one option "--prefix" already. the --with-libtool flag and its
>   data flow is aligned to that. i don't know how sucessful this is.

Makes sense.  Another (better) approach is an alternate Make2, hand
built. Doing manually first is essential before automating.  "Autotools"
deprives developers of this important feature.

> - most parts are implemented various times. it might make some sense to
>   deduplicate. i tried not to.

Things implemented multiple times is a maintenance headache.
Eventually, they diverge for no good reason and become a bigger
headache.  So, "deduplicate" is essential before considering merge to
master.

But multiple times might be an expedient way to get a first cut.

> - libtool raises portability issues upon linking plain object files into
>   a libtool library. hence i added a rule to compile .lo (libtool
>   object) instead.
> - the library version is initialized to 0:0:0. we should probably agree
>   on a higher one...
> 
> if this is working for you, we might want to include libtool, and
> default to --with-libtool, maybe just remove the non-libtool
> implementation... later.

When Microsoft supports libtool I might consider it.

You can't count on it always being available.  In fact, it didn't work
at first for me because I didn't have the "libtool-bin" package
installed.

But for those who like it, it should be available, something like a
plugin.

We need something that has plugin-like properties for things that can't
strictly be plugins.  All I can think of now is something like an
overlay.  That overlay could be automatically generated by having a git
branch that differs from master only in the respect being addressed,
and is maintained as such.