Re: License of m4/ltoptions.m4
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 aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 dependencies are inherited Bob at link time based on existing registered library dependencies. This Bob means that a library may link against a wrong library version, and the Bob error would propagate. 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 the libraries in the correct order, assuming that LDADD has been Bob used properly. I'm afraid I'm lost. I understand these two paragraphs as 1. dependencies are inherited at link time 2. libraries are already built (hence linked) in the correct order So when are the incorrect dependencies registered? At relink-time? Can't those of link-time be used? Bob One approach which could be used is for libtool to support a mode Bob where it is provided with a list of all the .la files for libraries to Bob be installed, and libtool returns a re-ordered list which is ordered Bob by increasing dependency. Automake would then use this to order its Bob installation of libtool libraries. Efficient implementation of this Bob capability in bourne shell sounds quite challenging. Not only that, but also supporting a arbitrary installation order of libraries in multi-Makefile projects. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* 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 the libraries in the correct order, assuming that LDADD has been Bob used properly. I'm afraid I'm lost. I understand these two paragraphs as 1. dependencies are inherited at link time 2. libraries are already built (hence linked) in the correct order So when are the incorrect dependencies registered? At relink-time? Can't those of link-time be used? Bob One approach which could be used is for libtool to support a mode Bob where it is provided with a list of all the .la files for libraries to Bob be installed, and libtool returns a re-ordered list which is ordered Bob by increasing dependency. Automake would then use this to order its Bob installation of libtool libraries. Efficient implementation of this Bob capability in bourne shell sounds quite challenging. Not only that, but also supporting a arbitrary installation order of libraries in multi-Makefile projects. Just to throw in random ideas: Let libtool output Makefile snippets in .libs/Makefile.libdep at link time, providing dependency information based on what it knows then. `make' is the canonical program to deal with topological sorting. Let make use these at install time, maybe through a generated script or some other mechanism (so that the Automake-generated Makefiles do not have to depend on .libs/Makefile.libdep to exist). No, I have not thought this through. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 #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 aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. Instead: As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses it as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may include it under the same distribution terms that you use for the rest of that package. 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? 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 embryo, the bytecode interpreter is 2500LOC in C. http://www.enlightenment.org/pages/embryo.html (down atm, use google cache) 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 scripts and implement local fixes, which may eventually become useful patches sent back to libtool. With a scheme which distributes compiled bytecode files, there is no possiblity of the end-user fixing the problem unless he installs the full libtool distribution package to he can modify the bytecode. That would be no less true of a compiled ltmain.c. It is already a little bit true of branch-2-0, since we build libtool (the script) from a bunch of m4sh code, and the output of a whole bunch of autoconf testing. Admittedly, you can still go in and tweak the code or the values. All that aside, we can have end-user tweakability, developer maintainability, runtime execution speed. Pick any two :-) 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
serial number of ltversion.m4 and libtoolize
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 PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 easier to add new platforms. Seems like a good idea, but I think it will prove difficult in practice -- unless we redo the way we have written all the macros. I think that it is a good enough idea to be worth discussing some more though. How do you envision the architecture for parsing and using the platform chunks? 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 too. The point being that we'd end up with the same (more or less) libtool.m4 as we have now, it would just be a heck of a lot easier to find the bits and pieces related to specific platforms, and would leave the platform independent stuff in a single file. 3.5. While we are there, maybe internationalise libltdl? I tend to agree with Ralf that we'd need to be careful that someone running libtoolize to get ltdl did not also get a requirement to have gettext. 9. Cross compilation test cases. Well, we just need lots and lots more test cases. We need platform specific test cases, platform indep test cases, test cases per bugfix (as Ralf did today), etc, etc. Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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, but I think it will prove difficult in practice -- unless we redo the way we have written all the macros. I think that it is a good enough idea to be worth discussing some more though. How do you envision the architecture for parsing and using the platform chunks? 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 too. The point being that we'd end up with the same (more or less) libtool.m4 as we have now, it would just be a heck of a lot easier to find the bits and pieces related to specific platforms, and would leave the platform independent stuff in a single file. Gah, perl? Blech. XML? Bah! Choke... rant It is a pity that Autoconf and Automake have a dependency on Perl, because that makes it easy to let it creep into Libtool. I've tried to learn Perl on at least two separate occasions, including buying and reading the entire Camel book. I can usually figure out roughly what's going on in someone else's code with a bit of head scratching, but I still can't come up with any maintainable code of my own. TMTOWTDI? TLTOWTUI! There's less than one way to understand it! /rant I'm also very wary of jumping on the... oh, wait: rant I'm also very wary of jumping on the XML bandwagon. I know it's the latest hip technology, and everyone wants in on the action, but XML is just lisp, with ugly paired angle bracket blobs to replace the parens. /rant There... I've got it off my chest, and feel much better now :-) Libtool already depends on C, so we don't need to resort to Perl. We can always prototype something in Perl, and then before we forget what all those strings of puntuation do, we should convert it to Shell and/or C. I think that porting ltmain to C or a byte-compiled language of some sort is definitely a win all round, so we can probably come up with an implementation in whatever language ltmain gets rewritten in eventually. I *do* think your idea fantastic idea btw... I guess the ball is in my court to figure out how we might do it without Perl and xslt now :-/ That'll teach me! :-o 3.5. While we are there, maybe internationalise libltdl? I tend to agree with Ralf that we'd need to be careful that someone running libtoolize to get ltdl did not also get a requirement to have gettext. Absolutely. But I don't think it is a difficult problem to solve with the more-or-less standard --disable-nls idiom. 9. Cross compilation test cases. Well, we just need lots and lots more test cases. We need platform specific test cases, platform indep test cases, test cases per bugfix (as Ralf did today), etc, etc. Couldn't agree more! 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 scripts and implement local fixes, which may eventually become useful patches sent back to libtool. With a scheme which distributes compiled bytecode files, there is no possiblity of the end-user fixing the problem unless he installs the full libtool distribution package to he can modify the bytecode. That would be no less true of a compiled ltmain.c. Even with a compiled ltmain.c, I expect that the platform specific rules would be encapsulated in data files rather than being compiled into ltmain.c. That would allow end-users to adjust the rules. Ltmain would simply be a rules processor. It is possible to also distribute the byte-code compiler so the end-user can modify source code, but the byte-code compiler is much larger and more complex than the byte-code execution processor so the size advantage is lost. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 be no less true of a compiled ltmain.c. Even with a compiled ltmain.c, I expect that the platform specific rules would be encapsulated in data files rather than being compiled into ltmain.c. That would allow end-users to adjust the rules. Ltmain would simply be a rules processor. That could also be achieved with a byte-code ltmain. It is possible to also distribute the byte-code compiler so the end-user can modify source code, but the byte-code compiler is much larger and more complex than the byte-code execution processor so the size advantage is lost. Agreed. If anyone is keen enough to fix the inner workings of libtool, it is not too onerous to ask them to download the libtool release tarball. 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
RE: serial number of ltversion.m4 and libtoolize
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 line of the following output: ~/ggi/ggi-core/libgii$ libtoolize --dry-run rm -f ./ltmain.sh ln -s /usr/autotool/devel/share/libtool/ltmain.sh ./ltmain.sh libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: `m4/libtool.m4' is already up to date. rm -f m4/argz.m4 ln -s /usr/autotool/devel/share/aclocal/argz.m4 m4/argz.m4 libtoolize: copying file `m4/argz.m4' libtoolize: `m4/ltoptions.m4' is already up to date. libtoolize: `m4/ltsugar.m4' is already up to date. libtoolize: warning: no serial number on `/usr/autotool/devel/share/aclocal/ltversion.m4', not copying. Cheers again, Peter ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 end. That would be no less true of a compiled ltmain.c. Even with a compiled ltmain.c, I expect that the platform specific rules would be encapsulated in data files rather than being compiled into ltmain.c. That would allow end-users to adjust the rules. Ltmain would simply be a rules processor. That could also be achieved with a byte-code ltmain. Yes, of course. 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 system. I see that the rules are scripted somehow (could use /bin/sh as `make' does) and are easily changed, but the core libtool engine works identically on all platforms, and does not need to be based on scripting. The main argument to use a VM for internal libtool logic would be to reduce code size so the libtool footprint is smaller. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 system. I see that the rules are scripted somehow (could use /bin/sh as `make' does) and are easily changed, but the core libtool engine works identically on all platforms, and does not need to be based on scripting. What an excellent idea! Care to throw together a straw-man design? The main argument to use a VM for internal libtool logic would be to reduce code size so the libtool footprint is smaller. Depending on the language chosen as input to the byte-code compiler, we might also be able to come up with something that is a better fit for the problem space. Writing rules-based ltmain in C might take a lot longer than writing it in a higher level language, and will probably take longer to work the bugs out of. I am not (yet) especially in favour of either C or an as yet undetermined byte-compilable language, but I would definitely like to explore the idea of replacing the creaky old ltmain.sh code :-) 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 need to teach it (or maybe a subsidiary script) to spit out link flags after poking around in a dependency chain of .la files. I'm maintaining that now :) so we can definitely do that g Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 get any use out of them, this means you actually need a version script that gets incrementally modified as new symbols are added. If you just globally attach the same symbol to all of the symbols, you're not really accomplishing much (other than enabling two different versions to be loaded into the same application, and -Bsymbolic solves that *DON'T SHOOT ME* :p). 9. Support multilibbing. Can you explain? 10. More testcases. Faster test suite. Please submit test cases for stuff that does not work. I've been playing with some test frameworks recently, the Autotest one that comes with Autoconf is fairly primitive but surprisingly useful (as you can just define your own m4 to improve it) -- I've still not found anything that can truly unit test C though (if we plan down that road). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 dependency chain of .la files. There's actually a couple of things pkg-config does that Libtool doesn't currently do. pkg-config's main job can be summed up simply as enabling parallel-installed -dev packages. Principally it provides the right -L and -l flags to link libraries, we can get this from Libtool. An an improvement would then be only providing the dependency -l flags on platforms that need it, and not on Linux for example. However it *also* provides the right -I flags to point at the include files. A GTK+ application will '#include gtk/gtkbutton.h' for example and require -I/usr/include/gtk-2.0 to actually be able to find that (or -1.0, -3.0, etc.) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 too. The point being that we'd end up with the same (more or less) libtool.m4 as we have now, it would just be a heck of a lot easier to find the bits and pieces related to specific platforms, and would leave the platform independent stuff in a single file. Gah, perl? Blech. XML? Bah! Choke... This does seem rather over-the-top to me ... the only thing worse I can think of would be using lisp for anything other than scaring comp-sci students with. I think that porting ltmain to C or a byte-compiled language of some sort is definitely a win all round, so we can probably come up with an implementation in whatever language ltmain gets rewritten in eventually. The trouble is that you need to either compile ltmain on every platform, or have an interpreter handy. I guess there could be a magic Automake-shimmy to make every binary depend on libtool, which can be compiled in-place in the source a bit like libintl. This scares me more than the shell script :p Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* 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 everything you said except about perl. Just curious... Do you mean that you disagree with my perl rant? Kind of. Perl readability depends on both the eye of the beholder and the mind of the writer. But I strongly agree on all the other cruft. Libtool already depends on C, so we don't need to resort to Perl. We can always prototype something in Perl, and then before we forget what all those strings of puntuation do, we should convert it to Shell and/or C. Or that you think prototyping in Perl is dumb? Nope. I rather think that it won't give libtool much that shell cannot. Use more shell functions. Why prototype in perl what you can write in shell (or other) right away? I think there is value in prototyping in HLL to work out algorithmic issues before writing the real implementation in a LLL for speed. Arguably, ltmain.sh is our HLL prototype. Except that it seems to be a good idea to separate platform details from rules at this point, so we probably need another prototype now :-l Why can't this separation be done in ltmain.sh? My vote: against everything but shell and C for ltmain. For the rules, make might prove fine (except that the portable set is quite limited). I'd do C++ (with STL), but that's out of the question portably-wise. rant Gah, C++? Bleh! /rant Kidding! Sure, introducing another dependency is only a good idea if there are definite tangible benefits. I've enumerated a few, but probably not enough to make it an obvious choice. Of course, the person who implements it gets the casting vote ;-) /me runs away quickly. :) Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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? It's a tricky enough situation that we should probably take it up with the FSF itself. It owns the copyright. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
* 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 maybe a subsidiary script) to spit out link flags after poking around in a dependency chain of .la files. There's actually a couple of things pkg-config does that Libtool doesn't currently do. pkg-config's main job can be summed up simply as enabling parallel-installed -dev packages. Principally it provides the right -L and -l flags to link libraries, we can get this from Libtool. An an improvement would then be only providing the dependency -l flags on platforms that need it, and not on Linux for example. I've so far been unaware of the reason why libtool does not set link_all_deplibs to `no' on linux, as you put in the Debian package. Can anybody point me to a reason/docs/thread explaining this? However it *also* provides the right -I flags to point at the include files. A GTK+ application will '#include gtk/gtkbutton.h' 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 want that (or it can even be) in a .la file or not. But letting libtool output both information might prove valuable. Absorbing pkgconfig in libtool in a way that each pkgconfig user must use libtool will pave way for quote some resistance, I'd expect. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage The core problem appears to be that an Automake-generated Makefile.in uses dependencies when building installable products but then installs them in destination_PRIMARY batches without observing the dependencies it already knows. Indeed, if Automake did not know the dependency graph of each object, it could not build them reliably. If Automake generated an install target for installable product, just as it generated a build target, would that not solve this problem? Like so: -- Makefile.am lib_LTLIBRARIES = foo.la bar.la foo_la_LIBADD = bar.la -- Makefile.in foo.la: bar.la $(LIBTOOL) ... install-foo.la: install-bar.la $(INSTALL) ... install-bar.la: $(INSTALL) ... ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 ) ltdl users if they choose not to make use of the translation capability. ) Do you mean zero runtime overhead? That's easy, and fairly standard already: ) ) #ifndef _ ) # ifdef ENABLE_NLS ) #include libintl.h ) #define _(Text) gettext ((Text)) ) # else ) #define _(Text) (Text) ) # endif ) #endif ) ) There are a few other tweaks that need to be done (see CVS M4), but for ) brevity I'll spare you the details :-) ) ) Obviously message catalogues and the like will make the distribution bigger ) though. As this trick takes effect at compile time, would this require that an embedded libltdl grow in size even if the functionality is never used? This is only part of the magic, but is the only change in the source code. If so, I think the point is to allow packagers who embed libltdl in other packages to choose a prenoninternationalized version (so the noni18n occurs at repackaging time rather than compile time). 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 should help there :-) 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 should help there :-) There are oodles of dangers here. For example, a package distribution maintainer for a particular OS may not agree with the package developer's choices so he will install his own libltdl with the extra message catalogues. This could make things very confusing/difficult for the package developer. There is already plenty of confusion caused by package distribution maintainers who replace the existing libtool in a package with one that they prefer. On the flip side, the package developer may choose to distribute an internationalized libltdl, which causes new issues for end-users and package distribution maintainers. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 there is no full dependency graph of each object. The build is dependent on careful ordering by the developer rather than Makefile dependencies. Thanks for the correction. If Automake descends into SUBDIRS to install in the same order it does to build and uses `make' dependencies to ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 the authors? It's a tricky enough situation that we should probably take it up with the FSF itself. It owns the copyright. Agreed. Why don't we work up a clause that we all like, and draft a note explaining why we need the exception, and then we can forward it to the FSF for consideration... Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 though subordinate Makefiles so there is no full dependency graph of each object. The build is dependent on careful ordering by the developer rather than Makefile dependencies. Thanks for the correction. If Automake descends into SUBDIRS to install in the same order it does to build and uses `make' dependencies to ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? That would be my assumption as well. The current library install mechanism does not ensure that libraries are installed in the same order that they are built. 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. Package developers usually already have the library installed on the system so they may not see the failure in their environment, but end-users do. 'make distcheck' helps significantly with discovering these problems. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
[ 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 one Makefile, this is possible (and mostly supported) but most projects depend on SUBDIRS to recurse though subordinate Makefiles so there is no full dependency graph of each object. The build is dependent on careful ordering by the developer rather than Makefile dependencies. Thanks for the correction. If Automake descends into SUBDIRS to install in the same order it does to build and uses `make' dependencies to ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? That would be my assumption as well. The current library install mechanism does not ensure that libraries are installed in the same order that they are built. This statement seems to me to imply that Automake should be able to do the job on its own, without any additional information from libtool, given the library dependencies are stated correctly in the Makefile.am's. So, can the user not enforce inter-Makefile dependencies through the use of `libfoo_la_DEPENDENCIES = sub/libbar.la' ? 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. Package developers usually already have the library installed on the system so they may not see the failure in their environment, but end-users do. 'make distcheck' helps significantly with discovering these problems. BTW, this topic shouldn't have any extra issues in the cases of staged installs (checked by `make distcheck') and cross-compilation, right? Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 use the .m4 file for other, proprietary reasons. How about this wording instead? As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute the resulting output files under the same terms that you use for the rest of the package. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 ensure proper ordering within each SUBDIR, then the products should relink/install in the correct order. Right? That would be my assumption as well. The current library install mechanism does not ensure that libraries are installed in the same order that they are built. This statement seems to me to imply that Automake should be able to do the job on its own, without any additional information from libtool, given the library dependencies are stated correctly in the Makefile.am's. I think so. Every working build order is a correct installation order. If the build succeeds, Automake knows one working build order. It therefore knows one workable installation order. So, can the user not enforce inter-Makefile dependencies through the use of `libfoo_la_DEPENDENCIES = sub/libbar.la' ? That would not improve installation order correctness at this time. 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 it is about to install before installing them. Unfortunately, this would keep the user from meaningfully specifying `install' options to, for example, make backup copies. As you say, using distcheck is a robust way to flush out these issues. Package developers usually already have the library installed on the system so they may not see the failure in their environment, but end-users do. 'make distcheck' helps significantly with discovering these problems. BTW, this topic shouldn't have any extra issues in the cases of staged installs (checked by `make distcheck') and cross-compilation, right? I cannot think of any. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 resulting output files under the same terms that you use for the Paul rest of the package. 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. I assume input to GNU Automake means read by aclocal to produce aclocal.m4. If so this text seems to imply that you can distribute aclocal.m4 (with an embedded copy of python.m4) under your licensing term only if you also distribute python.m4 (which is under GPL). But there is another case which I'd like to support: the case where python.m4 is distributed aside to aclocal.m4, and aclocal.m4 simply does m4_include([m4/python.m4]). Then python.m4 is not a resulting output file of aclocal. And still we'd like to relax the GPL. As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. 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. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 may distribute Paul the resulting output files under the same terms that you use for the Paul rest of the package. 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. Just trying to cover all bases to avoid more pain for future autotools versions. Note that libtoolize does actually read through aclocal.m4 and any files it m4_includes to find a few directory paths and decide whether to copy particular files. We might extend that functionality in future. The use of GNU Autoconf is to prevent someone creating their own tool and calling that Autoconf to circumvent the license. [[...]] As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. 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 prefer my wording :-) Bruce's would be kinda cool too. But frankly, I'd be flabbergasted is the FSF bought that :-( 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 it is about to install before installing them. Unfortunately, this would keep the user from meaningfully specifying `install' options to, for example, make backup copies. As you say, using distcheck is a robust way to flush out these issues. This won't work reliably because it is older (i.e. different shared library version) libraries which cause the problem. The older shared libraries should not be unlinked. The existing libraries may be discovered in a different directory than the new libraries are being intalled in. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 cannot pre-compute this installation order when it is run, and computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage Noah The core problem appears to be that an Automake-generated Noah Makefile.in uses dependencies when building installable Noah products but then installs them in destination_PRIMARY Noah batches without observing the dependencies it already Noah knows. Indeed, if Automake did not know the dependency Noah graph of each object, it could not build them reliably. Strictly speaking automake does not know these dependencies. It knows some dependencies, but because of the possibility to AC_SUBST variables for conditional linking, and doest not know exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@). However these dependencies are indeed known later at make time. In other word Makefile.in and Makefile.am do not have the necessary information to compute an installation order, but Makefile does. So yes, this order could be recorded during the build. Libtool already does that, doesn't it? If so it seems easier to get the dependencies from it. Noah If Automake generated an install target for installable Noah product, just as it generated a build target, would that Noah not solve this problem? This sounds appealing, but wouldn't this imply that if two libraries depends on another one, the later will be installed twice? -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 trying to cover all bases to avoid more pain for future autotools Gary versions. Note that libtoolize does actually read through aclocal.m4 Gary and any files it m4_includes to find a few directory paths and decide Gary whether to copy particular files. But none of the path you are looking for are specified in user files, not those we are considering. Also that argument would apply to Gettext as well, and maybe several other tools. We cannot list all of them and should not discriminate some of them. 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 with GNU Automake too, but I can understand it in some way.) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 with GNU Automake too, but I can understand it in some way.) Okay, that's fair enough. Let's drop GNU Libtool from the list of tools then. 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 allow any configuration-file generator? That simplifies it somewhat. Something like the following, perhaps? It also attempts to incorporate Gary's suggestions. As a special exception to the GNU General Public License, if you distribute this file as part of a package that automatically derives from this file a configuration script (and perhaps some associated intermediate files), then you may distribute this file and the derived files for that purpose, under the same terms that you use for the rest of the package. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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 intermediate files), Paul then you may distribute this file and the derived files Paul for that purpose, under the same terms that you use for Paul the rest of the package. [...] President Eggert, you have my vote! -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
(no subject)
Do you want a Watch? http://jbb.afeet.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
☆ネットアイドルあいのホームページ☆
lbgAChÅz[y[Wfr [µÜµ½ vCx[gÊ^â¿åÁÆ«íÇ¢iHjÊ^Æ©à AbvµÄÜ·©Éľ³¢Ëô http://www.eyc.jp/~apple/?id=bGlidG9vbEBnbnUub3Jn ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
