Re: [Libreoffice] build out of git repos - first steps

Hi Rajesh,

        First - great to see you again ! and thanks for getting involved with
LibreOffice. I believe Cedric was looking into this issue and probably
is the best guy to own it, nevertheless let me trample all over his turf
- since he's not replied yet (AFAICS) :-)

On Sun, 2010-10-17 at 11:48 +0530, Rajesh Sola wrote:
>             I found the issue "build out of git repos" intresting & and 
> planning to work on it

        Great - cleaning up this part of the build would be most helpful.

>      - Eliminate rawbuild directory completely
>      - create symlinks for each subdir(like inc, source etc) of 
> every module from CLONEDIR to OOBUILDDIR directly

        Ok - so this is all good for the Unix case; unfortunately I believe we
-may- need something different for Windows. Having said that I don't see
any windows conditionals in unpack as of now - which seems to suggest
that the symlinks / rsync works; Jesus - what do you recommend - can we
run the build with cygwin's simulated symlinks - or is that going to
make a slow Win32 build even slower ? :-)

>             - so that except unxlngi6.pro every other directory in each 
> module is a symlink

        Oh - hmm ? why do that ? surely the existing rawbuild/ approach of just
having symlinks for top level modules (eg. 'sw') works well - and is
proven to build correctly.

>              -  cleaning up, updating symlinks if some sub directories 
> added/removed in cloned repos.

        I would just ln -sf and have done with it ;-) of course, removing stale
links is another problem ...

> Please add your suggestions/comments on above changes..of course hacking 
> build.pl (without symlinks, clean sources under some location like 

        As I say, building in the old 'rawbuild' works - the problem is only
that we do not do this by default, instead having this rsynced clone
(that burns a ton of disk space for no really good reason ;-).

>       Also planning to work on "build progress tracker in system tray" 
> as it involves some similar understanding of build process as above,

        Right :-) there are some interesting choices there - how do we report
status ? I would tend to think that counting the total number of
directories we run dmake inside would work well. At the most simple that
could be done by parsing the build output for:

"Entering .*"

        then making a rough %age by the number of these we have seen vs. the
total number there were last time we built would provide quite a good
estimate. Perhaps better would be to hook that goodness into build.pl
itself - but ... who knows.

> how about choosing cmake in build process,

        Converting the whole source tree to cmake just to get some progress
feedback seems overkill ;-) We have a medium term plan, and a half-down
child-workspace from Oracle that switches to GNU Make.

        Anyhow - in general, I would prefer people to pick a single Easy Hack
at a time to take a mutex on, rather than trying to hold several - ie.
someone else may get to this build status task before you ... :-)

        HTH,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot