On Monday, June 13, 2011 17:22:27 Jie Zhang wrote: > On Mon, Jun 13, 2011 at 4:52 PM, Mike Frysinger wrote: > > On Mon, Jun 13, 2011 at 16:39, Jie Zhang wrote: > >> On Mon, Jun 13, 2011 at 4:14 PM, Mike Frysinger wrote: > >>> On Sun, Jun 12, 2011 at 23:45, Jie Zhang wrote: > >>>> Attached is a patch which should keep the dependencies accurate > >>>> without reintroducing the issue the user reported: "remove *.lo > >>>> twice". The idea comes from BFD. > >>> > >>> i dont think this is an improvement at all. this is exactly the kind > >>> of stuff i dont think should be anywhere in the source build files. > >> > >> This is the way documented in Automake manual to deal with such > >> situation. > > > > sorry, but where ? i'm not seeing these kind of rules in the manual. > > http://sources.redhat.com/automake/automake.html#Extending > > [quote] > Note that Automake does not make any distinction between rules with > commands and rules that only specify dependencies. So it is not > possible to append new dependencies to an automake-defined target > without redefining the entire rule. > [/quote] > > So when we add those bison generated head files to the dependencies, > we should redefine the entire rule.
i dont think that applies to my patch. i'm going through a variable which isnt known until after configure is run, so automake isnt detecting the rule as a dependency. automake is parsing Makefile.am and looking for explicit rules named "foo.o:" but there is only "$(foo)", so it doesnt change what it outputs to Makefile.in. > >>> the only thing wrong with my patch is that some .o files have an > >>> unnecessary dependency on these generated files. in practice, i dont > >>> think this matters at all. i did this so that we wouldnt have to > >>> maintain a list of object files (which might change names if libtool > >>> changes behavior). > >> > >> But there is nothing known wrong with my patch. > > > > what you posted is not really maintainable. i could post a new > > version of my simple patch which simply lists the exact objects and > > thus there wouldnt be anything wrong either, but i honestly dont think > > it makes any real world difference, and people will be able to > > understand either with a simple `make` background. > > If there are better fix, why not use it? i dont think it is a better fix. anything that involves directly invoking any compiler tool is not better imo. > >> The issue you are > >> worried about is in the future. It might come, it might not. I don't > >> think automake and libtool change a lot nowadays. So I don't think we > >> should worry about it. Anyway we can fix it when it unfortunately > >> happens. > > > > the code shouldnt require autotool experts to understand/fix. i'm > > afraid what you've posted would scare almost everyone from trying to > > touch it. > > No, you don't need to be an autotool expert to understand/fix it. I > never think I'm an autotool expert. The possible changes in the future > might be: > > * Automake is improved so we don't need to do that. Then we can remove > it. But if we don't remove it, it will still not break things. atm, we're tracking older versions to make it easier on people > * Automake changes some variables used in the rules in the patch. We > can just take a look at the generated rules in Makefile.in to see what > a new rule looks like and modify accordingly. this is more than many people can handle > * We don't use autotools and change to some other solution. Then we > don't need to care about this. i'm not aware of any viable replacements -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
