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

Thanks michael, for your valuable comments&  suggestions, will look into build.pl and get back with 
some
understanding in few days,

On Tuesday 19 October 2010 11:16 AM, Michael Meeks wrote:
> 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) :-)
>    
        Its my pleasure to involve in LibreOffice development, the concept of more liberated 
encouraged me to resume.

> 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 ? :-)
>    
        Hmm, not thought of win32 build issues

> >              - 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.
>
>    
        I mean, the present build.pl when creates unxlngi6.pro dir in one of the symlink under 
rawbuild, it is going to create under git repo also right? Of course
if expected build.pl can put built files some where else,this wont be an issue.


> >               -  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.
>    
        Can think of 2-3 types of status reports like no.of source files wise, no.of directories 
wise etc. and give an option to choose/switch one during build.

>    
> > 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.
>    
    Yes, Will work out status tracking with GNU Make only

>         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.
>
>    
Thanks&  Regards,

Rajesh Sola.