Re: [Libreoffice] tree open for gnumake hacking again ...

Hi Matúš,
On Tue, 26 Jul 2011 11:18:05 +0200
Matúš Kukan <matus.kukan@gmail.com> wrote:

> First: I can use templates from solenv/gbuild/templates? Asking mainly
> because of license part of file.

IANAL, so I will refrain from answering that one (I assume you intend
to change the license).

> Do we need for each module or even library FOO_DLLPUBLIC? Or I can
> just use SAL_DLLPUBLIC_EXPORT.

Almost. Every library where the header is used to link against the
symbol from another Library. In those cases SAL_DLLPUBLIC_EXPORT would
work on *nix, but not on Windows. SAL_DLLPUBLIC_EXPORT is enough for
plain UNO-libs which just export the UNO factory functions.

see
http://webcache.googleusercontent.com/search?q=cache:1iVDdEXF5bcJ:blogs.oracle.com/GullFOSS/entry/why_some_compilers_suck_more
for details.


> What to do with libraries?
> Can I break things on other platforms and somebody else will fix that?
> or should I really try to not.

At least trying is a good idea ;)

> In basctl there was: IF WNT SHL1STDLIBS+= $(SHELLLIB)
> (SHELLLIB=-lgdi32 -lshell32 -ladvapi32 -lcomdlg32)
> So I should add all of them (but I don't think all are really used) or
> just nothing and somebody will add the right one ?

While it is good to remove superfluous linking, I dont think breaking
master for that is a good idea. In case of doubt, file an easyhack
listing the suspicious linking and work through those later (or let
somebody else pick that task up).

> Can I also change names of libraries?
> -        Name = SPECIAL_NAME(animcore);
> +       Name = LIBNAME(animcore);

Yes, as long as they are not part of the URE (for UNO-API stability).

> And because of things like
> -SHL1IMPLIB= i$(TARGET) I should add something to RepositoryFixes?

RepositoryFixes is for all the adjustments where libs are not following
the usual conventions. The idea was, that when we once go binary
incompatible (LibreOffice 4.0 API), we can make RepositoryFixes.mk
empty and have alot more consistent naming (modulo external libs, where
we have no say in the naming). Using RepositoryFixes right now is also
a good idea, as renaming a lib in two build systems is just needless
pain (migrating to gbuild and renaming only there is much easier).

> And RepositoryFixes has section about WNT which has two parts but
> there are common things mentioned twice. Maybe we could reorganize
> that.
Sure, go ahead! RepositoryFixes will always be messy, I am afraid
though. Its part of its nature. (It was once called the "bad bank" of
the new build system).
 
> What to do with unused files or whole directories? remove or igore or
> ask each time?

If it is plain dead code: remove. If it is test code with the hope to
be turned in a unittest: keep, maybe open a EasyHack/Bug about it.

> I've seen somewhere .IF "$(L10N_framework)"=="". Is the same variable
> present in gbuild?

No.

> Last important: In scaddins there were idl files processed:
> http://opengrok.libreoffice.org/xref/calc/scaddins/source/analysis/makefile.mk#125
> Is it possible to add them into offapi or somewhere?

Possible: sure, if there are no good reasons to keep the separation.

> But I was able to use generated hpp files just with adding:
>     -I$(realpath $(WORKDIR)/UnoApiHeaders/offapi) \
> gb_Library_add_api,analysis,offapi was not enough, not sure why and
> how it works.

gb_Library_add_api adds an include path to $(OUTDIR)/inc/$(api) and
depends on the Package $(api). So to keep the scaddins stuff separate
you would need to create a Package that generates the headers to
$(OUTDIR)/inc/scaddinsapi for example. See the offapi/UnoApi_offapi.mk
and offapi/Package_offapi_inc.mk files for reference.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen