On Wed, Jul 1, 2009 at 3:50 AM, Ben Laurie<[email protected]> wrote: > > On Wed, Jul 1, 2009 at 11:11 AM, Ben Laurie<[email protected]> wrote: >> On Wed, Jul 1, 2009 at 8:22 AM, Ben Goodger (Google)<[email protected]> >> wrote: >>> Sounds like a dependency issue. Can you explicitly build the >>> "chrome_strings" target and then try building the target you were >>> trying to build again? >> >> $ make chrome_strings >> make: *** No rule to make target `chrome_strings'. Stop. >> >> BTW, if I try to build the missing file... >> >> $ make out/Debug/obj/gen/chrome/grit/generated_resources.h >> make: *** No rule to make target >> `out/Debug/obj/gen/chrome/grit/generated_resources.h'. Stop. >> >> However: >> >> $ make out/Debug/obj/gen/chrome/grit/renderer_resources.h >> make: Nothing to be done for >> `out/Debug/obj/gen/chrome/grit/renderer_resources.h'. > > OK, so this seems like a dependencies issue - and given the logic of > the makefiles, AUIU (i.e. hazily), I don't see how this is supposed to > work. > > If I add the line: > > $(obj)/chrome/browser/debugger/devtools_window.o: > $(obj)/gen/chrome/grit/generated_resources.h > > to chrome/debugger.mk > > then it all builds fine. According to my reading of the makefiles, > there's nothing to ensure this happens on a clean build because: > > a) There are not yet any dependency files, and > > b) Dependency files are not read for targets that will be built anyway > (according to the comments) > > What I now don't understand is why it works for anyone? > > Also, it seems to me that b) is a bad idea because files like > generated_resources.h, even if they do get rebuilt, might get rebuilt > at the wrong moment (i.e. too late for their dependencies).
That is a good insight! I am definitely not clear on how all of this works, but my understanding is that for any files we generate, the dependency is expressed in gyp explicitly. That is translated by the Makefile generator in the following way. Say the 'strings' target has an action 'grit' that generates the above header. Then in strings.mk we'll have action_strings_output = generated_resources.h (see WriteActions()) and if it builds any source files it'll have $(OBJS): $(action_strings_output) (see WriteSources()) so that the header is generated before we compile any objects in that target. then we have, for the entire target 'strings', a special file considered the 'output'. For executables/libraries this file is obvious; for pure generation steps it makes a stamp file. strings.stamp: $(action_strings_output) (see WriteTarget()) And then finally, anybody that 'depends' (in the gyp sense) on this process will depend on that stamp file (see ComputeDeps() for this computation). This all probably seems terribly roundabout, but is the natural evolution of something that has nearly worked any number of times and been broken by various crazy tricks our code plays. You can often use 'make -d' to get more info about what it's thinking about. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
