On 07/04/2011 10:05, Mathias Bauer wrote: > On 06.04.2011 19:47, Michael Stahl wrote: >> On 06/04/2011 18:45, tora - Takamichi Akiyama wrote: >>> Hello Christian, >>> >>> On 2011/04/06 20:55, Christian Lippka wrote: >>>> While Niklas and Daniel are absolutely right, make clean may not always >>>> be what you want. >>>> >>>> For example, if you just want to rebuild svx with debug and do a >>>> make -sr clean, your next make in sw module would rebuild a lot of >>>> stuff, since all dependency to svx would fire. >> actually, for a module like svx it shouldn't rebuild any cxx files in >> dependent modules (which takes up most of the time), because gbuild will >> preserve the timestamp of the original file when delivering. >> >> of course if headers are *generated*, then dependent cxx files will be >> rebuilt. >> >> hmm... on second thought, if you actually use the top-level makefile, then >> probably the cxx files will be rebuilt in this case... :( > > If "in this case" means: "if there are generated headers", this is true.
no, i mean for ordinary headers that are just copied. (that generated headers cause rebuild is really obvious...) for headers that are just copied, GNU make will consider the target in the outdir outdated, because, well, it doesn't exist, and will copy the header to the outdir. all targets that depend on the header will then be rebuilt, because their prerequisite (the delivered header) has been rebuilt. when using the top-level makefile, this includes cxx files in other modules. currently we are using build.pl invoke GNU make once per module. in this case, cxx files in dependent modules will _not_ be rebuilt, because the check whether to rebuild the cxx file is done by a _different_ GNU make process than the one which copies the header. the second make process will just check the timestamps of the header and object file, and we use cp --preserve=timestamp so these are the same as the source file and thus the same as when you built the dependent module the first time. of course the right question here is, why the hell are we copying all those headers? it seems pointless to me: they could just as well be included from the source directory instead of from the solver. > And IMHO it's the only way a sane build system should work. A build > system that relies on "manual" evaluation of dependencies by developers > (as the build.pl/dmake combo) is insane. Dependency evaluation is what > make tools and files are made for. > > In case of svx/sw the generated header files svxslots.hxx and > globlmn.hrc cause some rebuilds in sw. Perhaps this is a good starting > point to think about better dependencies. Files like these and the way > we are using them are annoying. We can do better. > > globlmn.hrc is doomed once we get the work to get rid of context menu > resource files finished. > In case we moved all slot files into a single module and build them only > if sdi files have changed, the second problem would be solved also. This > would treat sdi files pretty much like idl files. > > The number one reason why changing header files causes too much rebuilds > is that our classes and thus our header files are too large (so that > "including only what you need" doesn't work), that we have still too > much nested includes and that superfluous includes in source files > rarely get removed. this is of course true :) > Regards, > Mathias -- "Religion is the ultimate hubris of man." -- Hillgiant -- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help
