[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC] Moving ltmain.sh and libtool.m4 into Automake
From: |
Gary V. Vaughan |
Subject: |
[RFC] Moving ltmain.sh and libtool.m4 into Automake |
Date: |
Wed, 17 Oct 2012 16:41:07 +0700 |
Autotoolers,
For quite some time now I've been thinking about simplifying Libtool,
but I'm interested in feedback and more particularly buy-in from
Automake maintainers before I start the work, so that I have a better
idea of what direction I'm heading in...
Libtool is just (a complicated) compiler wrapper, to make building and
linking against libraries easy to specify... be that on the command
line with a direct libtool invocation, or from Makefile.am
specifications. I'm considering splitting the current libtool project
in two:
1. libltdl as a standalone runtime loader wrapper
2. libtool.m4/ltmain.sh to generate the libtool script
I think (2) belongs better into Automake alongside the other tool
wrappers it already carries, where it can decide whether to run the
libtool m4 macros and roll an appropriate compiler wrapper tailored for
the project using it (no need for all the C++/Java/Fortran goo in a C-
only project for example).
Another consideration is that rolling Libtool into Automake would make
using Libtool as a standalone script rather more difficult. Having
said that, my impression is that Libtool is rarely used that way in
any case, and further simplification may be possible by deliberately
dropping explicit support for that use case.
If I make this split and contribute the macros and ltmain.sh to Automake,
is this something anyone else would like? If so, do you like it enough
to wire it into Automake with an appropriate hunk of Perl?
If the consensus is that Automake is not a good home for the libtool
compiler wrapper, then I still plan to split Libtool into two projects
as outlined above to decouple and simplify somewhat -- although I have
some other things to attend to first, so it will not happen right away,
but more likely after the next release.
Thoughts?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)