On Mon, Jun 13, 2011 at 4:52 PM, Mike Frysinger <[email protected]> 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. >>> 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? >> 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. * 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. * We don't use autotools and change to some other solution. Then we don't need to care about this. So don't be scared away. :-) Jie ------------------------------------------------------------------------------ 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
