Re: [Gnucap-devel] libtool?

[Felix Salfelder]

Hi Al.

On Sun, May 01, 2016 at 03:08:55AM -0400, al davis wrote:
> > - i have no idea, what the cross-platform implications are.
> 
> Build systems are all about cross-platform implications

if you invent them. much less if you just use them...

> >   and i don't
> >   know, how the build system is meant to work,
> 
> The old build system is really just a modular Makefile. [..]

sure. i mean, it's not obvious how to extend it without changing the way
it might be meant to work. the TRUE* FALSE* thing being one example.

> 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.

there is no way to select alternative Make2 files. why would one more of
them be any better? make has variables, and it supports overrides.

> > - 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.

yes. imo the number of configure scripts should be reduced to one. maybe
two (one extra at top level). but it seems you have started already...

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

we have multiple ways to build gnucap. (this, autotools and cmake).
consider autotools the first cut. i am trying to port the essentials,
without adding another. i prefer the configure script over invoking the
compiler manually over fiddling with make files manually (YMMV).

> > - 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.

what do you mean by "support"? i have not heard of any library version on
'Microsoft' machines, leave alone a binary package distribution
mechanism that would profit from proper version numbers.

does "./configure; make" work on these anyway? (i think autotools
should, haven't checked).

> 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.

yes, that's why i proposed to include it. once it is working for you.
(whether or not it should be the default is debatable).

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

libtool is used as a plugin already. not the kind of gnucap-plugins, but
in the sense of "replaceable code".

$ ./configure --with-libtool
$ make LIBTOOL=whateverelse

will use whateverelse.

> 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.

we should certainly include a functional and complete build system in
the main package. and ./configure --help should tell about all the
available options...

cheers
felix