lbgAChÅz[y[Wfr
[µÜµ½
vCx[gÊ^â¿åÁÆ«íÇ¢iHjÊ^Æ©à
AbvµÄÜ·©Éľ³¢Ëô
http://www.eyc.jp/~apple/?id=bGlidG9vbEBnbnUub3Jn
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/ma
Do you want a Watch?
http://jbb.afeet.com
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> As a special exception to the GNU General Public License,
Paul> if you distribute this file as part of a package that
Paul> automatically derives from this file a configuration
Paul> script (and perhaps some associated intermedi
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> "or any derived output" is a lame attempt to allow tools such as
> aclocal (without singling out aclocal) to preprocess the file,
> as long as the intent is to build a configure script.
I like the idea, but how about if we generalize it to allo
Alexandre Duret-Lutz wrote:
"Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> The use of GNU Autoconf is to prevent someone creating their
Gary> own tool and calling that Autoconf to circumvent the license.
I don't have a problem with GNU Autoconf, only GNU Libtool :)
(And to some extent
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Alexandre Duret-Lutz wrote:
[...]
>> I don't understand the intent of "as input to GNU Autoconf, GNU
>> Automake, or GNU Libtool". AFAICT Libtool does not input m4
>> files, only the Autoconf tools and aclocal do.
Gary> Just try
>>> "Noah" == Noah Misch <[EMAIL PROTECTED]> writes:
Noah> On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
>> - the relinking dependency debacle:
>>
>> For libtool to relink libraries when installing them, all
>> dependencies must have been installed. However automake
On Wed, 10 Nov 2004, Noah Misch wrote:
A problem exists in that if a library is already installed on
the system, it may be used by accident, either at build time, or at
install time. This masks serious build/install ordering issues.
Yes.
Automake could unmask these issues by unlinking every file
Alexandre Duret-Lutz wrote:
"Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> As a special exception to the GNU General Public License, if you
Paul> distribute this file as part of a package that uses the file as input
Paul> to GNU Autoconf, GNU Automake, or GNU Libtool, then you ma
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> As a special exception to the GNU General Public License, if you
Paul> distribute this file as part of a package that uses the file as input
Paul> to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute
Paul> the
"Gary V. Vaughan" wrote:
> Here's another:
And another:
``The following specific files are hereby deemed "public domain" and
you may use them any way you see fit.''
After all, these things are only useful with the Auto* tools and
I do not believe that any of them are state secrets, so why spend
Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> Was anybody unhappy with the exception wording in my last post in the
> thread? If not we can start from there.
I worry that it's too generous, because it means that if the package
uses the .m4 file as input to autoconf, then the
On Wed, Nov 10, 2004 at 08:52:00PM +0100, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET:
> > On Wed, 10 Nov 2004, Noah Misch wrote:
> > >If Automake descends into SUBDIRS to install in the same order it
> > >does to build and uses `make' dependencies to e
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Was anybody unhappy with the exception wording in my last post in the
> thread? If not we can start from there.
I worry that it's too generous, because it means that if the package
uses the .m4 file as input to autoconf, then the package can also u
[ slightly reformatted ]
* Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET:
> On Wed, 10 Nov 2004, Noah Misch wrote:
> >On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
> >>The problem is that Automake does *not* know the dependency graph of
> >>each object. Within on
On Wed, 10 Nov 2004, Noah Misch wrote:
On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
The problem is that Automake does *not* know the dependency graph of
each object. Within one Makefile, this is possible (and mostly
supported) but most projects depend on SUBDIRS to recurse thou
On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
> The problem is that Automake does *not* know the dependency graph of
> each object. Within one Makefile, this is possible (and mostly
> supported) but most projects depend on SUBDIRS to recurse though
> subordinate Makefiles so
Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
However, even though our intentions are good, and we are merely
clarifying the existing spirit of the exception clauses we have used
all along, is it okay to just edit the license of existing files without
explicit permission from th
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl --disable-nls'
install a non-internationalised libltdl minus message catalogues into a
parent package. But yes, we would have to take care to do it carefully. An
improved post-2.0 testsuite s
Daniel Reed wrote:
On 2004-11-09T18:19-, Gary V. Vaughan wrote:
) Ralf Wildenhues wrote:
) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
) >>3.5. While we are there, maybe internationalise libltdl?
) > Please don't. If you do, make it possible to have zero(!) overhead for
On 2004-11-09T18:19-, Gary V. Vaughan wrote:
) Ralf Wildenhues wrote:
) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
) >>3.5. While we are there, maybe internationalise libltdl?
) > Please don't. If you do, make it possible to have zero(!) overhead for
) > ltdl users if t
On Wed, 10 Nov 2004, Noah Misch wrote:
On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
- the relinking dependency debacle:
For libtool to relink libraries when installing them, all
dependencies must have been installed. However automake cannot
pre-compute this installation
On Wed, 10 Nov 2004, Ralf Wildenhues wrote:
However it *also* provides the right -I flags to point at the include
files. A GTK+ application will '#include ' for example
and require -I/usr/include/gtk-2.0 to actually be able to find that (or
-1.0, -3.0, etc.)
That's a good feature. Dunno whether I
On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
> - the relinking dependency debacle:
>
> For libtool to relink libraries when installing them, all
> dependencies must have been installed. However automake cannot
> pre-compute this installation order when it is run, and
>
* Scott James Remnant wrote on Wed, Nov 10, 2004 at 04:43:48PM CET:
> On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
>
> > 6. Absorb the functionality of the aberration called pkg-config. Libtool
> > already has all the information it needs, we just need to teach it (or
> > ma
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> However, even though our intentions are good, and we are merely
> clarifying the existing spirit of the exception clauses we have used
> all along, is it okay to just edit the license of existing files without
> explicit permission from the authors?
* Ralf Wildenhues wrote on Wed, Nov 10, 2004 at 10:09:08AM CET:
> * Alexandre Duret-Lutz wrote on Wed, Nov 10, 2004 at 09:53:37AM CET:
>
[ library dependencies and `make install' ]
> >
> > Not only that, but also supporting a arbitrary installation
> > order of libraries in multi-Makefile projects
* Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 05:37:19PM CET:
> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET:
> >>Gah, perl? Blech. XML? Bah! Choke...
> >
> >>There... I've got it off my chest, and feel much better now :-)
> >
> > /me agrees on e
Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET:
>>Gah, perl? Blech. XML? Bah! Choke...
>>
>>
>
> *snip*
>
>>There... I've got it off my chest, and feel much better now :-)
>
>
> /me agrees on everything you said except about perl.
Just curious... D
* Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET:
> Peter O'Gorman wrote:
> > Gary V. Vaughan wrote:
>
> >>> Post 2.0:
> >
> >>> 1. Generate a libtool.m4 from a bunch of individual file, one per
> >>> platform, to make the job of a "platform maintainer" easier and make it
> >>> easi
On Wed, 2004-11-10 at 13:25 +, Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
> > Well, I haven't thought about it really, I was vaguely imagining running
> > a perl script during bootstrap which would take the bits and pieces and
> > put them all together. I am told that xslt could do this to
On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
> 6. Absorb the functionality of the aberration called pkg-config. Libtool
> already has all the information it needs, we just need to teach it (or
> maybe a subsidiary script) to spit out link flags after poking around
> in a
On Tue, 2004-11-09 at 16:29 +0100, Ralf Wildenhues wrote:
> 6. Versioned libraries. Although this is not very portable yet, it is a
> concept which IMHO needs support. Many people ask for it.
>
One of the principal problems is that you need to record when symbols
were added to the library to ge
On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
> > 5. Think about speed, compile mode needs to be as fast as possible, can
> > it be faster than it is?
>
> 6. Absorb the functionality of the aberration called pkg-config. Libtool
> already has all the information it needs, we just
Bob Friesenhahn wrote:
>
> When evaluating the direction to take for a C-based libtool, I tend to
> think of libtool being similar to `make' in that it is a rules
> processor. The process of "configuring" libtool would be a matter of
> selecting which collection of rules applies to the current sy
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
The main issue I see with using embryo (or small, or Java) or any other
byte-code/VM based machine is that it seems to make it much more
difficult for the end-user to fix problems on their
I wrote:
> The serial number of the generated m4/ltversion.m4 is not
> recognized by the libtoolize script. func_serial() does
> not expect dots in the serial numbers of the macro files.
>
> This is for branch-2-0.
I should perhaps also mention why I think this is a problem.
Consider the last lin
Bob Friesenhahn wrote:
> On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
>
>>>
>>> The main issue I see with using embryo (or small, or Java) or any other
>>> byte-code/VM based machine is that it seems to make it much more
>>> difficult for the end-user to fix problems on their end.
>>
>> That would
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
The main issue I see with using embryo (or small, or Java) or any other
byte-code/VM based machine is that it seems to make it much more
difficult for the end-user to fix problems on their end. With the
existing libtool they can hunt and peck through the
Peter O'Gorman wrote:
> Hi Gary,
Howdy!
> Gary V. Vaughan wrote:
>>> Post 2.0:
>
>
>>> 1. Generate a libtool.m4 from a bunch of individual file, one per
>>> platform, to make the job of a "platform maintainer" easier and make it
>>> easier to add new platforms.
>>
>> Seems like a good idea, bu
Hi Gary,
Gary V. Vaughan wrote:
Jolly good. ;-) When this thread dries up, can you summarise it back into
the TODO file in Libtool please?
Sure.
Post 2.0:
1. Generate a libtool.m4 from a bunch of individual file, one per
platform, to make the job of a "platform maintainer" easier and make it
easi
Hello!
The serial number of the generated m4/ltversion.m4 is not
recognized by the libtoolize script. func_serial() does
not expect dots in the serial numbers of the macro files.
This is for branch-2-0.
Cheers,
Peter
___
Libtool mailing list
[EMAIL
Hey Bob!
Bob Friesenhahn wrote:
> On Tue, 9 Nov 2004, Gary V. Vaughan wrote:
>
>> Bob Friesenhahn wrote:
>>
>>> There may be some other existing small shell/scripting implementation
>>> which please Unix programmers but are small enough to embed in other
>>> applications.
>>
>>
>> I rather like e
On second thoughts, why not take this opportunity to unify the license
exception between libtool and automake so we can share code more easily?
Gary V. Vaughan wrote:
Alexandre Duret-Lutz wrote:
"Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> Would you use the exact same wording in
Alexandre Duret-Lutz wrote:
"Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> Would you use the exact same wording in #2 that you
Paul> already uses in the aux scripts? Does that wording still
Paul> apply?
I think so. Another idea would be to use a bison-like exception
just to mat
* Alexandre Duret-Lutz wrote on Wed, Nov 10, 2004 at 09:53:37AM CET:
> >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> Automake can at least keep its part of the house in order by ensuring
> Bob> the correct library install order within the same Makefile. It does
> Bob> build
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> On Wed, 10 Nov 2004, Alexandre Duret-Lutz wrote:
[...]
>> 1. install all programs and libraries without relinking (in random order)
>> 2. relink everything (in random order)
[...]
Bob> I don't believe that this would work since dep
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> Would you use the exact same wording in #2 that you
Paul> already uses in the aux scripts? Does that wording still
Paul> apply?
I think so. Another idea would be to use a bison-like exception
just to match the license of aclo
48 matches
Mail list logo
