Re: libtool 1.5 tag woes (static/shared)

[Sander Niemeijer]

Bringing the discussion back to the list.

Begin forwarded message:

> > Hi Paolo,
> >
> > I think I start to understand it now. When I was writing my e-mail, 
> > the libtool mail archive site was also not reachable, but today it 
> > was working again, so I have been able to do some catching up.
> > As you already stated somewhere documentation about tags is rather 
> > non-existent, so forgive me when I'm making wrong assumptions here.
> >
> > If I understand you correctly then you are solving the 
> > -fomit-frame-pointer problem by creating a special tag which you will 
> > use by calling libtool with the --tag=<yourtag> option when 
> > compiling/linking your library. Although this will surely do the job 
> > I don't think it would be a really clean solution to the problem. The 
> > fact that you would have to build your own version of the libtool 
> > script (including this special tag) means that it won't be possible 
> > to build the shared/static library pair you want with the globally 
> > available libtool script.
> > What I think would be a more preferable approach is to have libtool 
> > command line options available that would let you provide additional 
> > options for static library compilation/linking and/or additional 
> > options for shared library compilation/linking. Something like:
> > libtool -extra-shared-flags='-fomit-frame-pointer' --mode=link 
> > LINK-COMMAND
>
> Yes, I had thought about it and also had implemented it with exactly 
> this name, but this would lead to a proliferation of
> flags that I don't like.  You are modifying the configuration, so a 
> tag is the appropriate place for this.

As far as I can see specifying shared/static library specific 
compilation/linking options is not changing the configuration. 
Especially if you only want to do this for one of your many libraries 
in your package.
If you wanted to have an additional linking option for both your static 
and shared version of your library you would add it as an (AM_)LDFLAGS 
item if you use automake or just add it to the libtool link command 
line.
If you don't see this as changing the configuration, then wanting to 
add a link option for just the static or just the shared version of a 
library shouldn't be considered a configuration change either IMHO.
I can understand that you may have some personal preference against 
having more flags, but if it is only personal preference, then maybe 
something has to give. I would opt for a 'best design' approach, which 
in my opinion would be to have the one or two extra libtool arguments 
introduced and not trying to 'pollute' the tags architecture of libtool 
with non-language related tags. But then again I'm no libtool tags 
expert, so maybe my 'pollute' statement is way off.

> Actually, I don't think that anyone uses the global libtool script :-)
>
> Paolo
>
> > Going for such an approach of course also eliminates your 'copying 
> > tags in an upward-compatible way' problem.
> >
> > Regards,
> > Sander
> >
> > On 18-nov-03, at 20:42, Paolo Bonzini wrote:
> >
> > > > In a previous posting you opted for reverting the -static/-shared
> > > > functionality and in the posting quoted below you are opting to make
> > > > the disable-static/disable-shared tags obsolete.
> > >
> > > The disable-static/disable-shared *tags* are not the *configure 
> > > options*.
> > > In the older post I proposed to revert the -static/-shared 
> > > functionality not
> > > because I fail to appreciate it, but because it has a duplicate: 
> > > indeed, my
> > > request for a -static option for libraries was dropped two or three 
> > > years
> > > ago :-) and instead, I was pointed to the disable-shared tag which 
> > > was
> > > available in the then active multi-language branch, which became 
> > > libtool 1.5
> > > later.
> > >
> > > In a more recent post, after having developed further my idea of 
> > > using tags
> > > for changes to the configurations, and not only for languages, I 
> > > noted that
> > > my macro has an asymmetry: due to the way these two tags are 
> > > implemented,
> > > they would not work with my macro.  Since an alternative was added 
> > > in the
> > > meanwhile, I proposed to obsolete them (also as a shortcut to keep 
> > > my patch
> > > simple and easily reviewable/updatable) instead of reverting Ralph's 
> > > patch.
> > >
> > > I do recognize I am somewhat contradicting myself, in that I am 
> > > proposing to
> > > obsolete the only precedent for "tags used to change the 
> > > configuration".
> > > However, the real problem is that the two special tags are 
> > > implemented
> > > specially and are not known to the configure script.
> > >
> > > Paolo

Regards,
Sander