/source/auxiliary/si/

ora/cd-5.3-3.2 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/solenv/gbuild/TargetLocations.mk
AgeCommit message (Collapse)Author
2018-07-04add --enable-split-debug for -gsplit-dwarfLuboš Luňák
https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html Change-Id: I2a02e23e46d7a54083249408f09fba87932b1d44 Reviewed-on: https://gerrit.libreoffice.org/56416 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-06-06(Partially) fix --with-help=html dependencies on .xhp filesStephan Bergmann
There are three rules in helpcontent2/CustomTarget_html.mk that process (with XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for en-US; or their translations in the workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other languages). Lists of all those .xhp files are defined in helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists. That has two issues (at least for the en-US case operating on the untranslated helpcontent2/source/text/ files): For one, if the content of those .xhp files changes, the relevant XSLT processing is not re-run. For another, if .xhp files are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the relevant XSLT processeing is not re-run, either. For the processing of translated .xhp files, there were already dependencies on those translated files in place. I assume (but have not really proved it) that those dependencies are already sufficient to cover both of the above issues. That only leaves the en-US case, operating on the untranslated files. The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*" ranging over the various "modules": sbasic, scalc, schart, etc.) are now made available in gb_AllLangHelp_*_HELPFILES variables. The contents of those variables is used instead of `find` to pass the relevant .xhp files to the XSLT processings. (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed individual files to the XSL processing without overflowing maximum command line lengths. Also, on Windows, var2file apparently writes CRLF line ends but the CR parts need to be filtered out again, and xargs problems must be worked around similar to df9edbcd2883cec2d0596133131cfbc220dee91f "Work around 'xargs: environment is too large for exec' errors on Windows".) However, those variables apparently cannot be used to specify dependencies for the three XSLT-processing rules. Presumably, the variables do not necessarily have their values assigned yet by the time the rules' dependencies are constructed (depending on the order in which .mk files are read?). So "dummy" gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all the relevant .xhp files (and which get constructed during gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES variables), and which the XSLT-processing rules in turn depend on. That makes sure that the XSLT-processing rules are re-run when the content of .xhp files changes or when new .xhp files are added. However, the above still fails to re-run the XSLT-processing rules when .xhp files are removed. This is the core part of a commit spanning core and helpcontent2. Change-Id: I0cb5f83097db17fbd7ae8b528418b0ec24bee602 Reviewed-on: https://gerrit.libreoffice.org/55363 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-02-22Fix clean-up of gb_UIConfig_get_a11yerrors_targetStephan Bergmann
The old code tried to remove non-exisiting *.a11yerrors files corresponding to a UIConfig's individual *.ui files, not the one single *.a11yerrors file corresponding to the UIConfig itself. Also, there's no need to have a UIA11YErrorsTarget merely for clean-up. Just do that clean-up as part of gb_UIConfig_get_clean_target. Change-Id: I6676f08496254398801bb75172c1326d1c843071 Reviewed-on: https://gerrit.libreoffice.org/50156 Reviewed-by: Samuel Thibault <sthibault@hypra.fr> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-02-20Integrate initial version of gla11y tool in the build systemSamuel Thibault
This is part of integrating an accessibility non-regression tool. This adds checks in configure.ac for the presence of python lxml which we will need, and adds support for calling the tool at build time, to check for definite UI errors. For now, that only emits errors for missing or duplicate accessibility relation targets, and senseless relations: a label being mnemonic for several widgets. Change-Id: Idda91b15b9a9e0322d16db33dfac8e03f2aa518c Reviewed-on: https://gerrit.libreoffice.org/49856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-11-24tdf#113787: gbuild: fix the version of cli_cppuhelper assemblyMichael Stahl
There is one usage of gb_Library_add_generated_cxxclrobjects in the entire repo, and regrettably generated C++/CLR objects weren't actually implemented in the new build system, so the assembly.cxx with its generated version number was simply ignored.
2017-07-21de-hrc various thingsCaolán McNamara
e.g. helpid[s].hrc -> helpids.h and insert include guards where missing move "ordinary" defines into .hxx files remove .hrc entries that are used as arguments to dialog factory when a dedicated method can be added instead Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e
2017-07-21migrate to boost::gettextCaolán McNamara
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-04-27cut top layer of detecting used bitmap resources in .src/.res filesCaolán McNamara
Change-Id: I476ff9f55c264983419d5410035c1dfe6e07d5a3 Reviewed-on: https://gerrit.libreoffice.org/37035 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-02-21When building with clang-cl on Windows, build CLR code with MSVCStephan Bergmann
...as clang-cl doesn't support the /clr switch. * In configure.ac, capture the MSCV version (that would be used if CC hadn't been overridden to use clang-cl) into MSVC_CXX. * The logic which flags to pass into gb_CObject__command_pattern is coded into the platform-agnostic LinkTarget.mk, so it's too late to try and filter all relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is a normal one built with the normal $CXX or a special /clr one built with $MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures this information early. * When building with clang-cl, the generated config_host/config_*.h files contain values suitable for clang-cl, but not for MSVC. But the .cxx files compiled with MSVC happen to include config_global.h, and would fail. Hack around that problem for now by introducing a hard-coded, minimal solenv/clang-cl/config_global.h that is found first when buliding such a CxxClrObject. Needs cleaning-up properly. Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33 Reviewed-on: https://gerrit.libreoffice.org/34509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-11-15New compilerplugins/clang unit testsStephan Bergmann
...to check that loplugin produces warnings/errors as expected: * Clang has a -verify switch that makes it easy to write test input .cxx files that list in comments all the warnings/errors that are expected, and let Clang check those expectations instead of generating object code. See include/clang/Frontend/VerifyDiagnosticConsumer.h in the Clang source tree for documentation. * Introduce a CompilerTest gbuild class that uses the existing LinkTarget class as much as possible. Checking the input files is implicitly phony, as the compilation step doesn't generate any object files, and the link step does nothing because there is no gb_LinkTarget_set_targettype for CompilerTest. The setup at least works for Clang on Linux (will need adaptions for Clang on Windows; compilers other than Clang are not relevant for now given this is used to check compilerplugins). * Definition of gb_CFLAGS_WERROR in solenv/gbuild/platform/com_GCC_defs.mk needs to be lazy ('=' vs. ':=') so that CompilerTest can override it: The Clang -verify mode wants the input files to specify whether the loplugin diagnostics are warnings or errros, so they consistently need to be errors independent of --enable-werror configuration. * A first (example) test is in compilerplugins/clang/test/salbool.cxx. The corresponding gbuild CompilerTest instance is in solenv/CompilerTest_compilerplugins_clang.mk for now. The reason for that odd split across compilerplugins/ and solenv/ is that there is no compilerplugins/Modules_compilerplugins.mk file, so this setup is the easiest hack for now (to be cleaned up). (Another area that could be improved is that all test files need to be listed explicitly in the CompilerTest_*.mk file, instead of, say, using all .c/.cxx/.m/.mm files in a specified directory.) * The test is run somewhat late during a top-level 'make', after loplugin has already been used in compilation. But it can be run manually (e.g., 'make solenv') when making changes to loplugin during development. Change-Id: I01e12fb84887d264ac03ef2484807458c2075af4
2016-08-18screenshots: add new global make targetArmin Le Grand
Up to now the screenshot creation was added/dependent of target slowcheck. Since quite some modules have added screenshot creations now, I added an own target 'screenshot' to allow to keep current slowcheck and screenshot creation separated Change-Id: I80a49a0db607edf8e0405672d570f624d29912e7
2016-06-18uitest: build system part for new uitestsMarkus Mohrhard
We now can call the uitests with make uitest.uickeck Change-Id: I20c73efd93c7987f3b841cd0e3e7842ee7a5dab9
2016-03-07drop handling of templates in SrsTargetDavid Tardon
Change-Id: I5445837ec4f647e91fe2aeab1251e48628f5e7f1
2015-10-22gbuild: incremental builds with --enable-pch are unsoundMichael Stahl
The problem is that the precompiled headers' dependency files are not run through concat-deps, hence they directly refer to headers of external libraries' headers, which are not targets in the build system; therefore re-building an external library does not cause the dependent PCH to re-build and (at least with MSVC) the object files don't depend on headers included via PCH anyway, so we get the recent link failure in comphelper with MSVC, which wasn't rebuilt for icu's ABI change. To fix that just use concat-deps, which re-writes header dependencies to UnpackedTarball target dependencies. Change-Id: Ic7555822925aaa1ff09b29bb73801fb83923bfab
2015-09-03add stagingcheck target for unstable/failing testsBjoern Michaelsen
Change-Id: I4d1e54bdf579b0d6dd143b3a68de259ab7d3d562
2015-07-04Fix typosAndrea Gelmini
Change-Id: Ic6415423f46aaee7ba90239a617c318cf92ae222 Reviewed-on: https://gerrit.libreoffice.org/16711 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>