sal/config.g sal/types.h and sal/osl/rtl includes in general

Lubos Lunak l.lunak at suse.cz
Wed Sep 19 07:02:27 PDT 2012


On Wednesday 19 of September 2012, d.ostrovsky at idaia.de wrote:
> Quoting Stephan Bergmann <sbergman at redhat.com>:
> >> On 09/18/2012 12:14 AM, Norbert Thiebaud wrote:
> >> [...]
> >> for 2/
> >> I propose to create a file 'lo.h', in solenv/inc/ for now... and start
> >> to bring all source code in conformance... [...]
> >
> > I'm not sure such a lo.h combining inclusion of multiple other
> > header files would be a good idea.  With the constant flux across
> > our code base, I think aiming at precise, minimal includes is a
> > better approach, as it helps achieving minimal rebuilds.
>
> +1 for that.
> Was spending hours (!) yesterday during rebuilds with total ccache
> misses because of recent header changes.

 And the build would have taken the time no matter what. If something as 
fundamental as the basic headers should be changed, which occassionally 
happens to be the case, then there's just no good way around it. There are of 
course bad ways around it, but the codebase is already full of those and 
there's really no need to add more. Minimal includes may be worth the effort 
if they actually save something, but that's not the case here.

 If you don't want to spend hours doing rebuilds, then it's much simpler to go 
around that. You can pull and rebuild only when you know you won't need the 
machine for some time. You can 'cp -a .git/ elsewhere/; cd elsewhere/; git 
checkout -f; git pull -r; git push' to avoid a possible rebuild just because 
you want to push. You can have checkout1/ and checkout2/ directories and work 
in one while you can pull and build in the other one. (having a make wrapper 
script doing 'cd $(readlink -e $(pwd)) && /usr/bin/make $@' makes it even 
possible to just always work in a symlink pointing to the active checkout). 
And I myself actually do all of these, even though I can built LO pretty 
fast. Feel free to write these down to the building wiki page if you think 
it's worth writing down.

> --enable-apps-only="base sw"
> if someone is working on one or two apps there is no reason to rebuild
> the whole suite all the time.

 This one would be nice to have (although presumably non-trivial to 
implement). And I'd support the make target not involving tests too.

-- 
 Lubos Lunak
 l.lunak at suse.cz


More information about the LibreOffice mailing list