Re: Creating lock file for compilers that don't support -c -o

[Sascha Schumann]

 I'd rather see a link to the POSIX standard defining link as atomic.

IEEE Std 1003.1-2003

http://www.opengroup.org/onlinepubs/007904975/functions/link.html

The link() function shall atomically create a new link for
the existing file and the link count of the file shall be
incremented by one.

- Sascha


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Sascha Schumann]

  There is one big question which must be answered first: will it have
  to be Autoconf 2.13 compatible?

We use it for the PHP project (80k lines configure script),
because 2.5x is 5 to 6 times slower and contains a
dependency-ignorant cache system.

So, please don't create incompatibilities, unless you really
have to.

- Sascha



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Sascha Schumann]

 I developed/maintain the configure script for ImageMagick.  While the
 total lines in the generated configure script is meaningless, it is
 less than 1/2 of what you report for PHP, and PHP's configure script
 is 4-8X larger than typical configure scripts for other large packages
 (e.g. 4X larger than the configure script for OpenSSH).  This seems
 odd to me.

There is lot of redundancy included which might be the reason
for the slow down.  I have thought about using shell
functions instead of expanding m4 macros all the time.  That
might improve things a bit.

 Having adopted every new Autoconf which has been released, I can
 happily say that as long as you avoid using undocumented Autoconf
 internals, it is not particularly difficult to make the minor
 modifications required to stay current.

PHP's system has been supporting autoconf 2.50 since its
inception.  2.5x is a burden on the developer's though who
improve the build system.  The more time an edit/build cycle
takes, the less likely someone will try to make modifications
and/or test them properly.

 I don't believe that the decision by some factions to stick with a
 particular Autoconf software version for the rest of time should be
 allowed to hinder the development of Libtool.

Well, if it is possible for a complex framework as ours to
maintain compatibility, there should be only few reasons why
it cannot work for libtool as well.  Of course, whoever
spends their time on libtool development gets to make the
final decision.

- Sascha



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Sascha Schumann]

[Cc line trimmed]

 me too!  :)

I think we have heard all arguments by now.  There is no need
to reiterate them.

Whatever the outcome of this thread might be -- I hope those
who work on libtool will continue to provide a toolkit which
is suitable for all of us -- developers and users alike.

Thanks
- Sascha




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Portability of find(1)

[Sascha Schumann]

 I'm looking for information on the portability of find(1).  Please,
 send me everything you know.  In particular, I think I'm understanding
 that `{}' is portably replaced by the argument only when alone, i.e.,
 exactly

'{}' can only be used portable, if it is a separate argument.

Also refer to SUSv2 which says on this topic

-exec utility_name [argument..] ;

[..] A utility_name or argument containing only the two
characters {} will be replaced by the current pathname. If a
utility_name or argument string contains the two characters
{}, but not just the two characters {}, it is
implementation-dependent whether find replaces those two
characters with the current pathname or uses the string
without change.

http://www.opengroup.org/onlinepubs/007908799/xcu/find.html

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool