On 22/04/13 19:55, Bjoern Michaelsen wrote: > 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?
the only thing the abstractions do here is get in the way. >>> - 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. that is not true, we need to register libraries so gbuild can detect attempted usages of non-existent libraries in partial builds. (or actually even non-partial builds as well currently given that many externals are implemented using gb_*_use_libraries with no corresponding Library). >> 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. clearly that problem doesn't happen often in practice. i can't remember a recent example. > 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 it appears that this could be combined with PCH to be even faster. though it's not immediately obvious to me how to implement it. presumably there is a requirement that all files must have the same command line parameters. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
