☆ネットアイドルあいのホームページ☆

2004-11-10 Thread love_girlpop
ƒlƒbƒgƒAƒCƒhƒ‹‚Ńz[ƒ€ƒy[ƒWƒfƒrƒ…[‚µ‚Ü‚µ‚½™ ƒvƒ‰ƒCƒx[ƒgŽÊ^‚â‚¿‚å‚Á‚Æ‚«‚í‚Ç‚¢iHjŽÊ^‚Æ‚©‚à ƒAƒbƒv‚µ‚Ä‚Ü‚·šŒ©‚É—ˆ‚Ä‚­‚¾‚³‚¢‚ˁô http://www.eyc.jp/~apple/?id=bGlidG9vbEBnbnUub3Jn ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/ma

(no subject)

2004-11-10 Thread Jill
Do you want a Watch? http://jbb.afeet.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

Re: License of m4/ltoptions.m4

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Paul Eggert
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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

Re: TODO

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Bruce Korb
"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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Noah Misch
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Paul Eggert
"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

Re: TODO

2004-11-10 Thread Ralf Wildenhues
[ 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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: TODO

2004-11-10 Thread Noah Misch
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Daniel Reed
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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: TODO

2004-11-10 Thread Noah Misch
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 >

Re: TODO

2004-11-10 Thread Ralf Wildenhues
* 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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Paul Eggert
"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?

Re: TODO

2004-11-10 Thread Ralf Wildenhues
* 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

Re: TODO

2004-11-10 Thread Ralf Wildenhues
* 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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Ralf Wildenhues
* 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

Re: TODO

2004-11-10 Thread Scott James Remnant
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

Re: TODO

2004-11-10 Thread Scott James Remnant
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

Re: TODO

2004-11-10 Thread Scott James Remnant
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

Re: TODO

2004-11-10 Thread Scott James Remnant
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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

RE: serial number of ltversion.m4 and libtoolize

2004-11-10 Thread Peter Ekberg
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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Bob Friesenhahn
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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Peter O'Gorman
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

serial number of ltversion.m4 and libtoolize

2004-11-10 Thread Peter Ekberg
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

Re: TODO

2004-11-10 Thread Gary V. Vaughan
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Gary V. Vaughan
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

Re: TODO

2004-11-10 Thread Ralf Wildenhues
* 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

Re: TODO

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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

Re: License of m4/ltoptions.m4

2004-11-10 Thread Alexandre Duret-Lutz
>>> "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