Re: dependencies for generated header files
От | Robert Haas |
---|---|
Тема | Re: dependencies for generated header files |
Дата | |
Msg-id | 603c8f070908111428p373c9c30o27e15c8716b05f04@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: dependencies for generated header files (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: dependencies for generated header files
Re: dependencies for generated header files |
Список | pgsql-hackers |
On Tue, Aug 11, 2009 at 4:38 PM, Peter Eisentraut<peter_e@gmx.net> wrote: > On Sunday 28 June 2009 21:21:35 Robert Haas wrote: >> I think that our dependencies for generated header files (gram.h, >> fmgroids.h, probes.h) are not as good as they could be. What we do >> right now is make src/backend/Makefile rebuild these before recursing >> through its subdirectories. This works OK for a top-level make, but >> if you run make further down in the tree (like under >> src/backend/commands) it won't necessarily rebuild everything that it >> should. >> >> The attached patch moves some of this logic from src/backend/Makefile >> to src/Makefile.global.in. That way, if you --enable-depend and then >> do something like "touch src/include/catalog/pg_proc.h" and then "cd >> src/backend/commands; make vacuum.o", it rebuilds fmgroids.h and then >> recompiles vacuum.c. Under HEAD, it just tells you that vacuum.o is >> up to date. > > I'm not convinced by this use case. Why do you want to rebuild vacuum.o > anyway? If you change something, then you probably want to rebuild postgres, > and that works fine without this change. Well, my original motivation for developing this patch was that I often go into a subdirectory and start hacking on a .c file and then type make to rebuild just that subdirectory (so it's easier to see warnings and errors). But sometimes I would edit a relevant header file and then the rebuild wouldn't happen. That bugged me. Your mileage may vary. > I'm concerned how this change moves random make rules into a global makefile. > This is exacerbated by your next patch, which among other things moves the > entire catalog list to build the various output files into Makefile.global, > far away from its home. *shrug* You don't have to accept the patch, but I'm unclear as to how make from a subdirectory will ever work reliably without something like this. The problem occurs when .c files have dependencies on files that are generated by a Makefile in some other subdirectory. So it's not random stuff: it's the stuff where that particular thing happens. ...Robert
В списке pgsql-hackers по дате отправления: