Hi Matúš, On Tue, 26 Jul 2011 11:18:05 +0200 Matúš Kukan <matus.ku...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
