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. >> 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. > 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. -mike ------------------------------------------------------------------------------ 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
