On Fri, Jun 17, 2011 at 2:59 AM, Mike Frysinger <[email protected]> wrote: > 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. > Not it does not apply to your patch. But it applies to the problem we are trying to resolve. The problem we are trying to resolve is we need to add more dependences to some targets in that Makefile.am. The manual says you need to redefining the entire rule for such targets. Your patch tries to hide those targets in a variable to hide your real intention, "extending dependences of some targets", from automake. This might cause trouble in unexpected way.
>> >>> 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. > I meant the new version of your simple patch you said you could post. I think the most important thing in for a Makefile is the correctness of dependence relations. If you can make the dependence more accurate, it will be better. >> >> 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 > For users, they should use the source from the release, which should already has Makefile.in generated. So they don't need to worry about those autotools. They should not need autotools installed to build the software. As developers, we should have an agreement on the lowest versions of autotools we use for development of UrJTAG. >> * 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 > This kind of argument makes no sense at all. I, or someone, or someone in future, really cannot handle some code in UrJTAG, should we remove those code? >> * 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 I just said some possible things might happen in future. I didn't propose to replace autotools in UrJTAG. Regards, 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
