Re: use --enable-pic [libtool--gary--1.0--patch-32]
* Noah Misch wrote on Tue, Aug 30, 2005 at 07:26:14PM CEST: On Tue, Aug 30, 2005 at 12:30:35PM +0100, Gary V. Vaughan wrote: * libltdl/m4/options.m4 (_LT_WITH_PIC): Renamed... (_LT_ENABLE_PIC): ...this. Adjust all callers. The configure option is now `--enable-pic', since `--with-pic' implies that the user wants to compile in an optional external package called pic. * doc/libtool.texi: Update documentation to match. `pic' is not an external package, but it is also not an optional feature. In particular, per Standards, `No `--enable' option should *ever* cause one feature to replace another.' --enable-pic effectively disables creation of the non-pic `.a' library and creates a PIC `.a' library. I suggest leaving things as they are or dropping the option entirely. There has been little mention of this option in the ChangeLog since 1999, when Thomas Tanner added the feature. The mail archives on lists.gnu.org do not go back that far; what was the use case for this feature? I cannot think of one. FWIW, I would be OK with this. Gary, what do you think about just changing the thinko in the documentation and leaving the rest as-is? Cheers, Ralf
Re: use --enable-pic [libtool--gary--1.0--patch-32]
* Gary V. Vaughan wrote on Tue, Aug 30, 2005 at 01:30:35PM CEST:
This patch continues to support --with{,out}-pic[={yes,no,both}, but
only advertises the more compliant --enable-pic in the calling
configure --help text.
There is no patch attached to your mail.
Okay to commit?
No, see above. :)
Cheers,
Ralf
Re: use --enable-pic [libtool--gary--1.0--patch-32]
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Aug 30, 2005 at 01:30:35PM CEST:
This patch continues to support --with{,out}-pic[={yes,no,both}, but
only advertises the more compliant --enable-pic in the calling
configure --help text.
There is no patch attached to your mail.
Okay to commit?
No, see above. :)
Eek! How odd...
http://tkd.kicks-ass.net/arch/[EMAIL
PROTECTED]/libtool--gary--1.0--patch-32?cmd=view_patches
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: use --enable-pic [libtool--gary--1.0--patch-32]
Hallo Ralf,
Thanks for the review. So much for my thinking this was a quick
5-minute patch, eh? ;-)
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Aug 30, 2005 at 02:42:00PM CEST:
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Aug 30, 2005 at 01:30:35PM CEST:
This patch continues to support --with{,out}-pic[={yes,no,both}, but
only advertises the more compliant --enable-pic in the calling
configure --help text.
Since the naming was unfortunate, and only documented in the test suite
documentation, I think it's OK to change from --with to --enable.
However, I'd like to test that it works before I approve. :)
Okay.
http://tkd.kicks-ass.net/arch/[EMAIL
PROTECTED]/libtool--gary--1.0--patch-32?cmd=view_patches
First bug present in HEAD: the old macro was apparently named
AC_LIBTOOL_PICMODE, not AC_LIBTOOL_PIC_MODE. Please also fix that
(2 instances) although it's orthogonal, thank you.
Fix applied to HEAD already.
Then, NEWS should get an entry (since with-pic was mentioned there,
too). Also, tests/demo-{pic,nopic}.test need updates.
Agreed.
Third, isn't the logic the other way round: instead of
| @item pic-only
| Change the default behaviour for @command{libtool} to try to use only
| @sc{pic} objects. The user may still override this default by specifying
| [EMAIL PROTECTED] to @command{configure}.
| [EMAIL PROTECTED] to @command{configure}.
shouldn't it be
| @item pic-only
| Change the default behaviour for @command{libtool} to try to use only
| @sc{pic} objects. The user may still override this default by specifying
| [EMAIL PROTECTED] to @command{configure}.
| [EMAIL PROTECTED] to @command{configure}.
Yep. That probably means the manual for 1.5 is wrong too... maybe this
patch (libtool--gary--1.0--patch-32..33) should be backported infact?
Fourth, the entry no-pic (a few lines below that) would need a similar
update, too, I believe. :)
Agreed.
Fifth, this can only be tested comprehensively (including the old macro
naming) if the ltoptions bug I just described is fixed. ;-
Proposed fix for that bug posted separately.
I've also addressed all of your concerns against -patch-32, as -patch-33
(posted separately) -- I'll merge both to HEAD and commit as one
changeset though.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: use --enable-pic [libtool--gary--1.0--patch-32]
On Tue, Aug 30, 2005 at 12:30:35PM +0100, Gary V. Vaughan wrote: * libltdl/m4/options.m4 (_LT_WITH_PIC): Renamed... (_LT_ENABLE_PIC): ...this. Adjust all callers. The configure option is now `--enable-pic', since `--with-pic' implies that the user wants to compile in an optional external package called pic. * doc/libtool.texi: Update documentation to match. `pic' is not an external package, but it is also not an optional feature. In particular, per Standards, `No `--enable' option should *ever* cause one feature to replace another.' --enable-pic effectively disables creation of the non-pic `.a' library and creates a PIC `.a' library. I suggest leaving things as they are or dropping the option entirely. There has been little mention of this option in the ChangeLog since 1999, when Thomas Tanner added the feature. The mail archives on lists.gnu.org do not go back that far; what was the use case for this feature? I cannot think of one.
