On Wed, Jul 1, 2009 at 3:33 PM, Evan Martin<[email protected]> wrote: > 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.
Yeah, I did a lot of that! As you say, the dependency is mentioned explicitly in the .gyp file and I have submitted a patch for that. If all of those are done correctly, then my comment above is redundant, but ... it seems to me that auto-dependency generation should be possible even for generated files. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
