Re: regex-0.12's regex.h seems to have a little bug
I forgot about this discussion for a while... Stepan Kasal [EMAIL PROTECTED] writes: Hello, On Thu, Sep 22, 2005 at 12:36:46PM +0200, Simon Josefsson wrote: Stepan Kasal [EMAIL PROTECTED] writes: Later on, when it was realized that a fix is needed, it was decided to wait for Autoconf 2.60, instead of converting gnulib back to the old scheme and later again to the new one. Right, sure. Btw, can I test this now? Is autoconf CVS HEAD sufficient? Do I need other tools from CVS? oops, we got too far. I'm afraid I no longer know what I'm speaking about. :-( What was the problem? That you cannot use AC_LIBOBJ/AC_LIBSOURCE with more than one lib subdirectory, right? Yes. What was the proposed solution? I'm not sure, I'm afraid I have missed it. See this thread: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/4281 The problem was that the proposed solution was contingent on the release of many other packages. I'm not even sure which CVS tag of which projects I should be using in order to start working on applying the fix to gnulib. But I _think_ that a prerequisite of the solution was that AC_LIBSOURCES and AC_LIBOBJ would take a second parameter which would specify the group that the file belongs to. This prerequisite is not in CVS Autoconf. This sound worse and worse to me. Moving filenames and directory structures from Makefile.am into configure.ac (possibly indirectly through aclocal.m4) seems wrong. But if somebody else will make this work and will support it, then I'm all for it. I'm afraid we need a design document for the solution. Then we can implement it. Have I missed it, or it is yet to be written? The following doesn't seem to be much relevant now, but: I recall some release dependency tree. CVS Automake requires CVS Autoconf. The other dependecies are not relevant here: CVS m4 requires CVS libtool (a.k.a. libtool 2.0). And perhaps CVS libtool depends on something, too... Which CVS branch should I be using? I recall some CVS tags in (I think it was) automake was dropped, and hacking resumed on another tag, or something. Thanks, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello again, On Fri, Sep 23, 2005 at 10:33:21AM +0200, Stepan Kasal wrote: I'm afraid we need a design document for the solution. Simon, perhaps you could volunteer. ... or you can just wait. I think I have something in mind now, and hopefully I'll write it down sometimes next week. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hi, I don't say I'm excited about the AC_LIBSOURCE macro, ... On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote: I'm not sure what the supposed advantage with AC_LIBSOURCES was compared to the old scheme. ... but I think I do remember what was the advantage: Imagine that a new file baz.c is added to a module. Then it is possible that you upgrade the existing files, including the m4 file which checks whether baz.c is needed, but that you forget to copy the new file, or you forget to add it to the list of distributed files. With the old scheme, the bug would be detected only on platforms where baz.c is needed. Typically, the developper uses a variant of GNU system, so most of the replacements are not needed; so the bug is not detected on his platform. With the AC_LIBSOURCES, Automake uses traces to obtain the list of distributed files, so we are sure that baz.c will be distributed. (And if it wasn't copied into the project, Automake will complain on every platform, no matter whether the file would be actually built there.) Yes, you might object that the mistake described above will not happen when people use gnulib-tool. But: - with the old scheme, the module maintainer had to add the file to the module description, _twice_: to the file list and to the lib_SOURCES variable in Makefile.am section. - with the new scheme you only add something like if test $baz_works != yes; then AC_LIBOBJ([baz]) fi and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. Please note that almost always you need to add a check for the feature anyway, so the code required by the new scheme presents almost no overhead, and, more importantly, the risk that you forget to add it is minimal. So that's it. Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Stepan Kasal [EMAIL PROTECTED] writes: Hi, I don't say I'm excited about the AC_LIBSOURCE macro, ... To understand what I'm writing below: I think AC_LIBSOURCE probably is the right solution, but it would have been nice to introduce it after the autoconf/automake/libtool/m4 releases had happened. Then we would have avoided the conflict with existing use of AC_LIBOBJ and AC_REPLACE_FUNCS. Requiring modern tools for gnulib users is probably ok, but requiring unreleased cvs releases probably is not. On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote: I'm not sure what the supposed advantage with AC_LIBSOURCES was compared to the old scheme. ... but I think I do remember what was the advantage: Imagine that a new file baz.c is added to a module. Then it is possible that you upgrade the existing files, including the m4 file which checks whether baz.c is needed, but that you forget to copy the new file, or you forget to add it to the list of distributed files. With the old scheme, the bug would be detected only on platforms where baz.c is needed. Typically, the developper uses a variant of GNU system, so most of the replacements are not needed; so the bug is not detected on his platform. With the AC_LIBSOURCES, Automake uses traces to obtain the list of distributed files, so we are sure that baz.c will be distributed. (And if it wasn't copied into the project, Automake will complain on every platform, no matter whether the file would be actually built there.) Yes, you might object that the mistake described above will not happen when people use gnulib-tool. Right. But: - with the old scheme, the module maintainer had to add the file to the module description, _twice_: to the file list and to the lib_SOURCES variable in Makefile.am section. Module maintainers always has to do the right thing. This potential mistake is possible to detect through a script, so if this was a genuine problem in the old scheme, we could write that script. - with the new scheme you only add something like if test $baz_works != yes; then AC_LIBOBJ([baz]) fi and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. This doesn't seem like a huge improvement. Please note that almost always you need to add a check for the feature anyway, so the code required by the new scheme presents almost no overhead, and, more importantly, the risk that you forget to add it is minimal. Problem is, the new scheme causes real problems if you used AC_LIBOBJ or AC_REPLACE_FUNCS before, and put the LTLIBOBJ in another directory than the gnulib files. Regards, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Julien PUYDT [EMAIL PROTECTED] writes: Paul Eggert a écrit : Julien PUYDT [EMAIL PROTECTED] writes: Stepan Kasal a écrit : I suggest that you get the files from gnulib CVS on savannah. Those are GPL and not LGPL ; No, they can be released under either the GPL or the LGPL. If you use gnulib-tool to obtain that source code, it turns the copyright notice into LGPL for you automatically. Hmmm... gnulib-tool wants to install it in a project -- which I don't want : I just need a posix regex library. Gnulib-tool doesn't seem to permit to just get the sources. I'll CC: this to bug-gnulib to see if the gnulib-tool experts can help out on here. I must admit that I'm no licence guru, and wonder why those files aren't just under the LGPL... after all the downgrading from GPL to LGPL is even done automatically by a script ! Historical reasons. Some projects don't use gnulib-tool even today, and these older projects typically want GPL. Coreutils is an example (and a source of a lot of the gnulib code). Arguably this should all be converted to do it the way that you suggest, but that'd take some work ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
