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
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
