* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 06:26:23PM CEST: > > Ah, yes. I see what you mean now. Unfortunately, I don't think your > patch will always work -- because of timestamp dependencies between > $prefix/share/aclocal, $prefix/share/libtool/libltdl, > $prefix/share/libtool/libltdl/libltdl, > $prefix/share/libtool/libltdl/loaders and > $prefix/share/libtool/libltdl/config :-( > > I think we need a giant nobase_libtool_DATA that lists all these files > in the right order, and then some directory shuffling in install-hook to > put everything in the right place in the install tree. And maybe some > libtoolize twiddling to find everything correctly...
Why? share/aclocal comes first, then libtool/config, then libtool/libltdl, and the last ones in proper order. I'm not sure libtoolize should be changed. While Bob and I agreed that it was a good idea to have libtoolize update timestamps, this bears a problem: On my machine, several of the above files are installed the same second. So, on the client machine where libtoolize is executed, they will have the same time. If libtoolize were to update time stamps, then it would need to know the order (and could _not_ infer it from timestamps). But _then_ it would not matter at all which time the installed files had anyway. Not at all. So in that case you could just leave it all to libtoolize to do the ordering. My thought so far was, that it's sufficient to do the ordering in "make install" as I've mentioned above, and leave the "tar hack" in libtoolize. > Ralf Wildenhues wrote: > >No. All you need to do is specify all files in the correct order, > >and then have them installed and uninstalled by Automaken rules > >(something like `aclocal_DATA = $(aclocalfiles)' should suffice). > >We might have to forbid parallel "make install". I don't mind. > > > >Oh, well. If you don't fix this, then I'll just have to put this in > >my patch as well, I guess. > > I'll leave it for your patch, both to keep mine from getting any bigger, > and because of my thoughts above... OK. I'll post a first version of it soon after your commit. In a new thread. Let's discuss then. > >>The attached now passes distcheck. > > > >Does it pass `make install'? > > Yes. This one too. Also distcheck and installcheck still pass. Very good. Thanks. > >Can you libtoolize and libtoolize --ltdl > >a client package from the installed? > > Yes. I've added writing a test for this to my TODO: > http://tkd.kicks-ass.net/WebWiki/GnuLibtoolProject/ToDo/LibtoolizeTest OK. > >My idea of reviewing is: if I don't allow through a patch with known > >regressions, things will eventually have to get better. So I don't > >approve of this patch, because it introduces regressions. > > Works for me :-D Well, the missing bit is this, which I sent to you privately (but meant to send in public, sorry): | Another regression: on GNU/Linux, after bootstrap, configure, make: | make[2]: *** No rule to make target `dlopen.la', needed by `libltdl/libltdl.la'. Stop. | | ltdl.m4 needs to be adjusted for this, I guess. I also guess this | change will need adjustments in all of Makefile.am, libtoolize.m4sh. LT_DLLOADERS and LT_DLPREOPEN will have to be created differently depending on whether libltdl is built from the toplevel Makefile or from libltdl/Makefile. (I believe this would be another issue Bob has posted about a loong time ago, when he tried to build GraphicsMagick/ltdl/libltdl.la directly from GraphicsMagick/Makefile.) Other than that, your patch looks quite good now. Cheers, Ralf
