On Thursday 09 July 2009 05:08:22 Garrett Cooper wrote: > On Wed, Jul 8, 2009 at 5:42 PM, Mike Frysinger wrote: > > On Wednesday 08 July 2009 20:21:11 Garrett Cooper wrote: > >> On Wed, Jul 8, 2009 at 4:53 PM, Mike Frysinger wrote: > > testcases/Makefile: > > i dont get all these xxx_DEPS variables and the install-testcases-bin > > target > > xxx_DEPS aren't used in typical situations. They are used in different > situations where one _must_ preserve dependency ordering. People > should NOT have to use these except with code generation, upper-level > target dependencies (my next stop after this all gets said and done, > e.g. if I do a submake from somewhere within testcases/kernel, I > better well have libltp.a built beforehand :)...), etc.
yes, but in the patch you posted, i didnt see why any of those needed to be in the Makefile's in question. i dont have a problem adding knobs, but i do when they're used incorrectly or not at all. i guess i'll wait until your follow up patch to check this stuff again > >> > why cant testcases/kernel/Makefile leverage these .mk files ? the > >> > whole point was to get away from these custom written jobbies ... > >> > >> Some of these Makefiles get a bit ugly with the pre- and post- junk... > >> There are a small number of Makefiles that are haunted by this work, > >> but then again I did some more rework with the generic_trunk_target > >> define. > > > > so that means you'll fix the Makefile to use the .mk files > > Yes. Again, these are bad hacks to work around the fact that these are > initial commits, and the fact that the rest of the source tree isn't > up to date with the new system (that will take ~3 days with straight > work and verification, but I'd quote a week and a half because of > random junk that can get in the way of getting things done). Only in a > few key Makefiles are these hacks required. testcases/Makefile is just > one of these examples. Here's the comment: ok, transitional hacks which are commented should be fine. i dont recall seeing this comment in the patch posted for review though ;). > >> > debugging/optimization/warning/stripping flags shouldnt be added in > >> > any Makefile that is being converted to these common .mk files. same > >> > for any DEBUG_XXX flags. > >> > >> Agreed. I was just duplicating what already existed, hoping that we > >> could sweep up this stuff after everything was in and the base > >> infrastructure was stable. > > > > i'd prefer we scrub the crap now > > Yes, but how and when should this stuff be done, and in what way? is > the ultimate question. If I were to toss in every dumb warning > compiler flag imaginable (which believe it or not _is_ the default for > the proprietary code we compile), my group in Cisco would never be > able to compile LTP because of coding issues. How much is enough, and > how much is too little? create a mirrored set of W*FLAG variables in the top level and stick the defaults in there. then all sub level should be punted. for now, use -Wall only. we can save the -Wextra/-Werror/etc... bs for a later date. i.e. the top level .mk should have: WFLAGS ?= -Wall WCFLAGS ?= $(WFLAGS) WCXXFLAGS ?= $(WFLAGS) ... CFLAGS += $(WCFLAGS) CXXFLAGS += $(WCXXFLAGS) ... keep language-dedicated flags available because there are language-specific warnings that if added to the wrong language, you get even more warnings (gcc warning you that this warning flag is not appropriate ;x) > >> > i dont see the point in declaring empty rules like "install: ;". if > >> > they're declared .PHONY, there is no need to add explicit rules to sub > >> > Makefiles. > >> > >> They're there to avoid errors with targets not being found if I'm > >> running recursive Make rules over the entire directory tree. So, I > >> agree it's silly, but if you have a better idea, I'm all ears and I'll > >> get on it ASAP. I'm trying to avoid cramming more variables into the > >> Make system because it will only generate more confusion... > > > > let's look at testcases/kernel/include/Makefile. how would a missing > > install target here generate an error ? > > testcases/kernel calls install recursively. I don't want to create > annoying subvariables for all, install, clean, and whatever other > recursive target I can think of, because even though I know how to, it > only serves to confuse and complicate the purpose of the system > (that's part of the reason why I'm the only individual, apart from two > others in a team of about 100, who can stumble around our complicated > build system at work). sorry, i'm still not following. why would the default install target not work in testcases/kernel/include/Makefile ? if there are no subdirs to recurse into and there are no default targets to compile, what would the default install do exactly ? -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
_______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
