Hi, On Mon, Apr 22, 2013 at 07:06:13PM +0200, Michael Stahl wrote: > well... all of the abstractions in gbuild don't help much for external > libraries. the abstractions expect the build targets to follow certain > conventions, and in many cases enforce such conventions, but external > libraries are not under our control and don't conform to any sort of > conventions, especially on Windows. > > so for external libraries something like gbuild actually doesn't offer > any benefits; you need to fit the external build into the conventions > imposed by gbuild (such as dependencies for everything and namespacing > issues) but don't get much benefit from that because every external is > unique in its own way. the only reason why we build externals with > gbuild is that we don't want to have yet another build system for them.
True, but in this case we are already not building the external project with gbuild, essentially using the external projects native build and treating it as a black-box -- trusting upstream to know what we are doing (and if not: fixing it there). The remaining titbits are essentially normal packagers work, but then they the abstractions arent that important in that case either, right? > fortunately the de-construction of solver is already in progress :) good riddance ;) > > - three-layer-office (now effectly two-layer office) > > a lot could be simplified by ridding ourselves of that madness > hmmm... i'm not sure if a one-layer office is really that much simpler > than a 2-layer one... mostly the difference is just a bunch of different > RPATH mappings on unixes. ... which is AFAIKS the only remaining fundamental reason then to have this global register_library_foo magic at all. > i definitely think that PCH is worth its weight given how significantly > it speeds up MSVC builds. without PCH we would probably be talking > about needing 20 windows tinderboxes for gerrit, not 10. Ya, I know, I still fear the 'only breaks on windows'-errors (because you essentially include way more than you use etc.). But maybe that fear is just a phantom of the pre-"remove tooltypes"-era. And then there is the stuff like that e.g. /MP could be used having e.g. gbuild to pipe compile commands to small buildqueue-program (prebuild a la concat-deps) which then executes a batch at once, sparing us compiler startups, which might or might not be faster than PCH with individual calls. http://msdn.microsoft.com/en-us/library/vstudio/bb385193.aspx All this messy exclusive-or stuff on Windows together with the facts like that its unlikely that another project of our size uses PCH together with e.g. showIncludes makes me a bit jumpy and dizzy (and one has a risk of painting oneself in a corner with every move). ;) > > Finally, let me encourage you to become/stay a 'build expert' yourself at > > least > > to the point that you can judge if adding yet another feature/scenario to > > the > > build system will introduce new complexity(*). > > meh... we can't demand everybody become a build expert :) I dont think having everyone tweaking on it would be a good thing even, but enough of an idea about it to have a basic opinion on what to do and what not is a good think IMHO. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
