Re: gbuild support for external projects

Hi,

On Tue, Aug 21, 2012 at 02:04:14PM +0200, Matúš Kukan wrote:
> Hi David,
>
> On 21 August 2012 09:00, David Tardon <dtardon@redhat.com> wrote:
> > Hi all,
> >
> > I have created a new gbuild class UnpackedTarball that handles preparing
> > sources for external project: unpacking, patching and a bit more
>
> Nice, I was considering asking about gbuildizing-external-libs status

Why do you think there had been any progress? :-) Actually I only
created this class because I needed it for converting extras, which uses
some external templates, fonts, etc. from OxygenOffice (the original way
to handle them was to unpack them over the source tree in ./download. I
will refrain from commenting on this.)

> > As for the rest of the external modules, my current idea is to use
> > free-form makefile, like CustomTarget, for everything but preparation of
> > sources. That would match the current dmake makefiles pretty well, I
> > think...
>
> Sounds fine, I am still not sure if I am going to take part in
> gbuildizing these.
> Maybe I will help with few.

Great. I have already marked external projects in
https://wiki.documentfoundation.org/Development/Build_System/Module_status
(most of the uncoverted ones, which is not surprising :-) I am
additionally going to mark the modules that are built purely by dmake
and maybe even add some notes about complexity of the makefile.

> > The code lives on branch feature/gbuild_external. I am pretty confident
> > it will not break on Windows, but I will not mind testers :-) If there
> > are no violent objectives, I will merge it to master in 1-2 days.
>
> This time I am not going to test it but I had a look.
>
> You've changed cygpath -u $(TARFILE_LOCATION) to cygpath -m $(TARFILE_LOCATION),
> that's wrong, moreover you have forgot to use
> gb_UnpackedTarget_TARFILE_LOCATION ?

Really? Oh, really. Crap. Fixed now.

> Also seems that you don't use $(STRIP_COMPONENTS) defined in configure.

Right, I should have used that. Fixed.

D.