gbuild support for external projects
dtardon at redhat.com
Wed Aug 22 22:15:14 PDT 2012
On Tue, Aug 21, 2012 at 02:04:14PM +0200, Matúš Kukan wrote:
> Hi David,
> On 21 August 2012 09:00, David Tardon <dtardon at 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
(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.
More information about the LibreOffice