On Mon, Jun 13, 2011 at 5:22 PM, Jie Zhang <[email protected]> wrote: > 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? >
Btw, I just tried your patch. It did not work: make[3]: Entering directory `/home/jie/sources/urjtag/svn/trunk/src/svf' YACC svf_bison.c CC svf.lo LEX svf_flex.c CC libsvf_flex_la-svf_flex.lo svf.c:56:23: fatal error: svf_bison.h: No such file or directory compilation terminated. make[3]: *** [svf.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... svf_flex.l:47:23: fatal error: svf_bison.h: No such file or directory compilation terminated. make[3]: *** [libsvf_flex_la-svf_flex.lo] Error 1 updating svf_bison.h make[3]: Leaving directory `/home/jie/sources/urjtag/svn/trunk/src/svf' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jie/sources/urjtag/svn/trunk/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jie/sources/urjtag/svn/trunk' make: *** [all] Error 2 I found this with make ./configure --enable-maintainer-mode make -j4 >>> 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
