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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.