[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Moving and libtool.m4 into Automake

From: Peter Rosin
Subject: Re: [RFC] Moving and libtool.m4 into Automake
Date: Thu, 18 Oct 2012 14:08:39 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

Hi Gary!

[dropping Automake@, since that part seems to have been shot down]

On 2012-10-17 11:41, Gary V. Vaughan wrote:
> 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
> specifications.  I'm considering splitting the current libtool project
> in two:
>   1. libltdl as a standalone runtime loader wrapper
>   2. libtool.m4/ 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 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? 

I'm working on some libltdl preloader issues with MSVC, and I must say
that the preloader is rather tightly coupled with libtool, with symbol
lookup table generation for libltdl in the libtool script. Your description
above feels like an attempt to describe the situation in a way that is
a little bit too simplistic. The patches I currently have for the MSVC
issues feels like the kind of stuff you would not want to coordinate
between two packages. So, what's the plan regarding the preloader in the
libltdl/libtool split? Where will e.g. func_generate_dlsyms sit? That
function is clearly an libltdl thing which interacts with libltdl
internals, but I don't see any really good alternative to having that
code inside the libtool script.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]