summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)Author
2017-04-06tdf#106359: register .iqy in MSI and treat them as templatesMike Kaganski
Change-Id: I7ae94c7717fbea03d96c539e05eeb565bafefd9f Reviewed-on: https://gerrit.libreoffice.org/36188 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-04-06Added help blurb for make verboseManfred Blume
Change-Id: Ibf06e37acc4b6ea69863abc9267152278c4598be Reviewed-on: https://gerrit.libreoffice.org/35770 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-04-04Missing str(...) when an arg is itself a css::uno::Sequence<...>Stephan Bergmann
Change-Id: I54529e7086014a2feba89eb73f3b368d36f758b8
2017-03-27Remove last use of md5sum (in building)Bryan Quigley
Switch to using sha256sum for checking if files change. Not for security, just so we don't need to check for md5sum. We also change the Windows installer to rely on the perm md5 digest instead of the environment variable. The code to do this was already in directory.pm Change-Id: I24aed542c6201abf030fdd62116aec3f8ea3513b Reviewed-on: https://gerrit.libreoffice.org/35140 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-03-26Fix gpgme packagingThorsten Behrens
Change-Id: I26ef55b8a7a210f9d86becd4f0aa10c2598681fd
2017-03-25Make loplugin:loopvartoosmall find more suspicious casesStephan Bergmann
...where the "controlling expression" of any sort of loop contains a sub- expression of the form var < val where the type of var is smaller than that of val. Theoretically, this could turn up lots of false positives, but practically it didn't run into any. Most findings have been cleaned up over the last weeks. There's just a handful remaining places that are hard to clean up, so I flagged them here with (deliberately awkward) sal::static_int_cast for later clean-up. Change-Id: I0f735d46dda15b9b336150095df65cf247e9d6d3 Reviewed-on: https://gerrit.libreoffice.org/35682 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-25Add loplugin:redundantinlineStephan Bergmann
...after it had recently been run with 6cb9e6dad798ec59f055aebe84a9c4a21e4be40d "Remove redundant 'inline' keyword" Change-Id: I7f3ee2ff1c32988dcff7245c64b50fe20b0a5e79 Reviewed-on: https://gerrit.libreoffice.org/35681 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-25Fix typosAndrea Gelmini
Change-Id: I4eda687db6ad8d41e6a28430c76b288510da605d Reviewed-on: https://gerrit.libreoffice.org/35645 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-03-24use VS 2015 to target XP with the 7.1A SDKChristian Lohmaier
Change-Id: I527a524c282d4314e57c30cdd9eb89bff38443db
2017-03-22Fix passing plain char into ctype.h is* functionsStephan Bergmann
Change-Id: I3d1fd585ba7f0bd8f6d074f0d2b86a20fa366072
2017-03-22codesigning script for macosx compained about double signingNorbert Thiebaud
Release build of 5.3.2.1 failed in codesign apparently LibreOfficePython.framework was being signed more than once, which cause codesign to fail and due to a recent patch to harden the codesign wrapper, the build itself to fail This does not address why some part are signed multiple time but merely tell codesign to ignore the issue and just sign This also fix a bash un-initialize variable warning and capture output of codesign in case of error to be able to diagnose things. Change-Id: Ibd6752702feb2bdf5163ac30ed7a3fd9c86f961c Reviewed-on: https://gerrit.libreoffice.org/35407 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2017-03-22gbuild: PythonTest depends on python.exe wrapper on WNTMichael Stahl
Change-Id: Idfd2a6d68fecfb5a473938a74a9020f76fbc2c4b
2017-03-22gbuild: MSVC: unbreak CPPUNITTRACE='$(DEVENV)'Michael Stahl
... which is unlikely to contain the strings "gdb" or "lldb". (regression from c38a4d9ce248b4b3fcc9208b25dfa599fe506ac0) Change-Id: I355069ec512232898b246d2b0bf8912831f0c80a
2017-03-20Fix version number in scp2-generated version ini-file UpdateID variableStephan Bergmann
USERDIRPRODUCTVERSION is stuck at 4 now (as its main use is for the version number of the UserInstallation directory), so use LIBO_VERSION_MAJOR instead (like generation of the version ini-file counterpart for instdir/ does in instsetoo_native/CustomTarget_setup.mk). Change-Id: Ib87536d335487383940cff2f69c864a33f05bbee Reviewed-on: https://gerrit.libreoffice.org/35301 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2017-03-19uitest: allow to specify a different configuration for testsMarkus Mohrhard
Change-Id: I29dec3237c46007a5c3dce02d70052a4891ec73f Reviewed-on: https://gerrit.libreoffice.org/35439 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2017-03-19tdf#87075: Filter out unused directories from FILELISTsStephan Bergmann
...so that on macOS dictionary extensions don't pollute LibreOffice.app's Contents/Resources/extensions/ with empty directories (that would then show up as phantom extenions in the Extension Manager). Change-Id: Iacff73e931885cde0fe507e384de80e9bd38d475
2017-03-16Fix typosAndrea Gelmini
Change-Id: I1488e2147fa0cd4a821eb5bfe172a58a4e396ace Reviewed-on: https://gerrit.libreoffice.org/35224 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2017-03-14Revert "Is gbuildtojson missing support for ExternalPackage?"Miklos Vajna
This reverts commit d8a47a23114ce9b4a743d0da35dfb93dadc07d11. It does not seem to be necessary after ee9cb85e9adc03693141a106630a4f278b4e93ac (gpgme: change gb_LinkTarget__use_gpgmepp to depend on package, 2017-03-10) fixed the root cause. Change-Id: I0e421d29d37853b0f4dd9d2ce4acf0cc1d09882f
2017-03-11Fix passing /DEBUG:FASTLINK linker optionStephan Bergmann
...which needs to be past at the end of the command line, after a /link option. Looks like at least MSVC 2015 Update 3 silently ignores the garbage /D option -DEBUG:fastlink, while clang-cl complains. Fixes 96af392ba495383927dc886f13a1f5a5cc46d9c1 "Use /debug:fastlink linker option to improve link performance". Change-Id: Ib679d4ce3ac4a7622ba7b066edbfe1872892137a Reviewed-on: https://gerrit.libreoffice.org/35048 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-03-10Fix comment to match realityTor Lillqvist
Change-Id: I13eb327673af451cc81d4134ec8fedb33702c0ac
2017-03-09gbuild: fix LIBPATH for LIBRARY_X64 with MSVC 2017Michael Stahl
Change-Id: I88601e8ad3d21554d6b8166bd7689e0a3b8b3a9f
2017-03-09Add missing CxxClrObject caseStephan Bergmann
Based on shm_get's (?) patch at <http://pastebin.com/yCghrjWX>. According to SweetShark on IRC, the reason for writing these phony files is: "IIRC not having them resulted in the builds being slow n windows as touching them required forks and windows is unionized and introduced the 35-fork-week or something." Change-Id: Ie0e6e2aa4e56ab620325ea55b4513e185db38ae7
2017-03-09Remove stray CR from inputStephan Bergmann
...that remained there with recent Cygwin/Bash version, which apparently had changes to their Unix-vs.-DOS line end handling Change-Id: Ib4c7c924362f9e93066e544ed5214fe589aa5336 Reviewed-on: https://gerrit.libreoffice.org/34990 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2017-03-09"/CxxObject/" etc. part was missing from generate_phony_line outputStephan Bergmann
Change-Id: I973468aab05f85c39b33bbf7be7f3ee389273c21
2017-03-06masOS codesign: Use of unset variable is an errorAndras Timar
Change-Id: I270b7ab66d502e767a62e7e98ec3cefe7b9646d5
2017-03-05Is gbuildtojson missing support for ExternalPackage?Stephan Bergmann
(Now that xmlsecurity/Executable_pdfverify.mk mentions that since f764d67da42caa71fd5e02146b1ca32680ae2f6e "Fix Executable_pdfverify dependencies on Linux".) Probably---but how am I supposed to fix that tempfile mess? So just take xmlsecurity out of the module list until somebody knowledgeable about gbuildtojson fixes that. [...] > mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/ > mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/CppunitTest/ > LD_LIBRARY_PATH=/data/lo/core/instdir/program:/data/lo/core/instdir/program:/data/lo/core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/data/lo/core/instdir/program:/data/lo/core/instdir/program" /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/Executable/gbuildtojson --makefile=/data/lo/core/TMPDIR/gbuild.X1C36q --linktarget=/data/lo/core/TMPDIR/gbuild.0zidFs --ilibtarget=/data/lo/core/TMPDIR/gbuild.LCl6Cf --cxxobjects=/data/lo/core/TMPDIR/gbuild.r4VEGz --yaccobjects=/data/lo/core/TMPDIR/gbuild.V6y0Sc --objcobjects=/data/lo/core/TMPDIR/gbuild.LBrqAl --objcxxobjects=/data/lo/core/TMPDIR/gbuild.WVv4ht --cxxclrobjects=/data/lo/core/TMPDIR/gbuild.H6vJbO --asmobjects=/data/lo/core/TMPDIR/gbuild.8hALYD --lexobjects=/data/lo/core/TMPDIR/gbuild.DOfpRn --gencobjects=/data/lo/core/TMPDIR/gbuild.0ErRmu --gencxxobjects=/data/lo/core/TMPDIR/gbuild.w2TAEg --cobjects=/data/lo/core/TMPDIR/gbuild.igfxay --javaobjects=/data/lo/core/TMPDIR/gbuild.WcfpOt --pythonobjects=/data/lo/core/TMPDIR/gbuild.O4Myeb --cflags=/data/lo/core/TMPDIR/gbuild.GRNm3B --cflagsappend=/data/lo/core/TMPDIR/gbuild.IwFfCF --cxxflags=/data/lo/core/TMPDIR/gbuild.FBXArw --cxxflagsappend=/data/lo/core/TMPDIR/gbuild.nKdQ4d --objcflags=/data/lo/core/TMPDIR/gbuild.ZbiwYX --objcflagsappend=/data/lo/core/TMPDIR/gbuild.Ahmn93 --objcxxflags=/data/lo/core/TMPDIR/gbuild.4PbfJo --objcxxflagsappend=/data/lo/core/TMPDIR/gbuild.DgMO0i --cxxclrflags=/data/lo/core/TMPDIR/gbuild.St2OX9 --cxxclrflagsappend=/data/lo/core/TMPDIR/gbuild.6UuMxo --defs=/data/lo/core/TMPDIR/gbuild.wbazch --include=/data/lo/core/TMPDIR/gbuild.KgrLWd --linked_libs=/data/lo/core/TMPDIR/gbuild.x4MaDG --linked_static_libs=/data/lo/core/TMPDIR/gbuild.OulkWx > /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/libtest_xmlsecurity_dialogs_test.so > [build EPK] gpgme > touch /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme > touch: cannot touch '/data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme': No such file or directory > make: *** [/data/lo/core/TMPDIR/gbuildqy7pkkpc/solenv/gbuild/ExternalPackage.mk:33: /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme] Error 1 > E > ====================================================================== > ERROR: test_gbuildtojson (gbuildtojson.CheckGbuildToJsonModules) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/data/lo/core/solenv/qa/python/gbuildtojson.py", line 142, in test_gbuildtojson > subprocess.check_call([self.bash, bashscriptname.replace('\\', '/')]) > File "/data/lo/core/instdir/program/python-core-3.5.0/lib/subprocess.py", line 271, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['bash', '/data/lo/core/TMPDIR/gbuild707bz2lq']' returned non-zero exit status 2 > > ---------------------------------------------------------------------- > Ran 2 tests in 53.237s > > FAILED (errors=1) > > Error: a unit test failed, please do one of: > make PythonTest_solenv_python CPPUNITTRACE="gdb --args" > # for interactive debugging on Linux > make PythonTest_solenv_python VALGRIND=memcheck > # for memory checking > make PythonTest_solenv_python DEBUGCPPUNIT=TRUE > # for exception catching > > make[1]: *** [/data/lo/core/solenv/gbuild/PythonTest.mk:36: /data/lo/core/workdir/PythonTest/solenv_python/done] Error 1 > make: *** [Makefile:161: PythonTest_solenv_python] Error 2 Change-Id: If8717f42657ae63ba468b5945f98e02090df58c9
2017-03-03[API CHANGE] Remove SAL_CONSTEXPR againStephan Bergmann
...now that LIBO_INTERNAL_ONLY always has constexpr support. It had been added for LO 5.0 (effectively always expanding to nothing for !LIBO_INTERNAL_ONLY), not wrapped in '#if LIBO_INTERNAL_ONLY' presumably because it was assumed to be used freely in URE include files, but turned out to be only used in LIBO_INTERNAL_ONLY code. It is unlikely that any 3rd party code made use of it. Change-Id: I68970c5a2e2d7ef68ac5b79efc8dc1de54c43198
2017-03-03Use /debug:fastlink linker option to improve link performanceDavid Ostrovsky
/debug:fastlink improve build performance and reduce resources consumption. When this linker oprion is used the linker-produced program database (PDB) files doesn’t have any private symbol information. Debug information is distributed among input object and library files, and the linker PDB just serves as an indexing database. Obviously, this provides a huge performance benefit for the daily developer builds. fastlink PDB files cannot be shared with another developer on the team or uploaded directly to symbol server. There is spcial tooling which is able to create a full PDB from the /debug:fastlink PDB on demand: mspdbcmf: [1]. The integration of mspdbcmf is beyond the scope of this change. [1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/ Change-Id: I14e29cf116407b420598f692c8d6d851e686268b Reviewed-on: https://gerrit.libreoffice.org/34330 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2017-03-03Fix typosAndrea Gelmini
Change-Id: Ib25dadb25d8c2df1361de194f74cf3ddd459650d Reviewed-on: https://gerrit.libreoffice.org/34783 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-03-01uitest: finally a working dependency on the build target for uicheckMarkus Mohrhard
Change-Id: Icaf1de556ae20027e27321750197ed574b508435
2017-03-01let the top level uicheck depend on the buildMarkus Mohrhard
Change-Id: I3dbbf84af75fd5ec3598302252ee1103bb9d5596
2017-02-28Fix gb_Extension_LICENSEFILE_DEFAULTStephan Bergmann
...post 3c946d688627ba0c31bcb37dfed4e6e180608854 "Put also the LICENSE file in Resources on macOS" Change-Id: I0a3435cc973d09e029ce4133d62544e4e432f6b5
2017-02-28Add back tests that got lostStephan Bergmann
...with 198c41c4fe8be4ce8a6ddab43ae0c5f17a4889ac "new loplugin unoany" Change-Id: Ia4e59356ad8ef3af899209a287ac5326e1389c5e
2017-02-28new loplugin unoanyNoel Grandin
Change-Id: I5d6c4a67cb2a09e7cd5bd620c6b262d188701b89 Reviewed-on: https://gerrit.libreoffice.org/34714 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-02-23solenv(gcc-wrappers): remove trailing space of includepathMark Hung
Change-Id: Ic14140f197a2c5e1632fd27cfae38ca4eff9bd8c Reviewed-on: https://gerrit.libreoffice.org/34562 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-02-22Improve error handling and fix some problemsTor Lillqvist
Use the -e and -o pipefail bash option to make the script fail more reliably if some command inside a pipeline fails. Use the -u option to catch mistyped variable names. Move the signing of executables in the bundle's Contents/MacOS after signing nested bundles. Change-Id: I21d441bcb2dbfc19b0cb5718b76402b1686d2239
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>
2017-02-21Kill bitrot Emscripten experimentKhaled Hosny
Change-Id: I1cd5331157e684afb01e6555168ce646194c6ff2 Reviewed-on: https://gerrit.libreoffice.org/34493 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
2017-02-19uitest: allow tests in each moduleMarkus Mohrhard
Change-Id: I95be6c97e7c01159f274397b636ef0599d872c0f
2017-02-16Capture loplugin:redundantcast status-quo wrt const_castStephan Bergmann
...including some double-warnings that'll get cleaned up shortly Change-Id: I14e9796f2846a6bb61e4c93dfb23cba6488ea2e6
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-08gbuild, python3: stop defining SOLARIS, and remove SOLARIS patchMichael Stahl
It's faster to change our code not to rely on -DSOLARIS than to wait for python developers to remove such nonsense from their public headers. Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
2017-02-01tdf#105311 VC++ Runtime installed in wrong directoryDavid Ostrovsky
Starting from MSVC 14.0, the directory table layout of VC++ Runtime merge module changed. As consequence, all MSI produced with newer compilers, including MSVC 15.0 (aka VS 2017) are broken in term that the VC++ Runtime DLLs are installed in the wrong directory, e.g.: C:\System64. According to the specification for merging merge module (msm), see: "Authoring Merge Module Directory Tables": [1], custom action 51 (set property) must be emitted for every directory name in the merge module directory table if the directory name is starting with the standard directory name. Quoting it here: " When a predefined directory is included in a merge module, the merge tool automatically adds a Custom Action Type 51 to the target database. The merge module author must ensure that a CustomAction table is also included. The CustomAction table may be empty, but this table is required to exist in the target database and ensures that the modified predefined directories are written to the correct locations. For example, when a system directory is included in a merge module, the merge module author must ensure that a Custom Action table exists. Note that the matching algorithm for the generation of these type 51 custom actions only checks that the directory name begins with one of the predefined SystemFolder properties. It does not verify that the directory name exactly equals the directory property. Any directory beginning with one of these standard folder names gets a type 51 custom action, even if the rest of the name is not a GUID. Authors need to take care that this does not generate false positive matches, and unintended custom action generation, on derivative primary keys that begin with one of the SystemFolder properties." Rectify the problem by analyzing the directory table from the merge module, checking whether the directory name starts with the standard prefix name and if it is the case, emitting custom action 51 to set this variable to the standard directory name. Implementation details: We use the existing facility for emitting the custom action table events including referencing them in the corresponding sequence tables. Given that the specification above doesn't mention what sequence table should be referencing this emitted custom action, we reversed engineer this information from WiX toolkit. Merging the VC++ CRT module with WiX toolkit and investigating the resulting MSI with Orca MSI reader, reveals that these sequence tables were referencing from these sequence tables: * AdminExecuteSequence * AdminUISequence * AdvtExecuteSequence * InstallExecuteSequence * InstallUISequence Replicate this behaviour here as well. Note, though, that custom actions are generally not referenced in AdminUISequence and AdvtExecuteSequence tables in LibreOffice MSI building tool chain. Rendering of the custom action is achieved by programmatic emulation of custom action in SCP module. Consider this similar SCP module based action: Name = "MigrateInstallPath"; Typ = "321"; Source = "shlxtmsi.dll"; Target = "MigrateInstallPath"; Inbinarytable = 1; Assignment1 = ("InstallExecuteSequence", "", "CostInitialize"); Assignment2 = ("InstallUISequence", "", "CostInitialize"); We instantiate the following data structure to emit custom action System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1: Name = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1" Typ = "51" Source = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1" Target = "[System64Folder]" Styles = "NO_FILES" Assignment1 = ("AdminExecuteSequence", "", "CostInitialize") Assignment2 = ("InstallExecuteSequence", "", "CostInitialize") Assignment3 = ("InstallUISequence", "", "CostInitialize") [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx Change-Id: I2fbd37ff63298d99b2ba1b6afe6e875f56d8e378 Reviewed-on: https://gerrit.libreoffice.org/33366 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-01-27Make plugin rewriting work on Windows tooStephan Bergmann
...in a somewhat hacked-up way for now (see the TODO comment) Change-Id: Ida89fb8257b876cfca05b3048ce15996091c5703
2017-01-27Use 'CPT' (for "compilerplugins test") instead of 'C??'Tor Lillqvist
Change-Id: I783a121b43223bbd0fd3f6250b2e009a77c87a85
2017-01-26unittest gbuildtojsonjan Iversen
Rename of FLEX to LEX needs to be done in the unittest as well. Change-Id: Ic038fa01d65edb5724c3d9dc8a04c72c6367372d
2017-01-26gbuildtojson support for yacc files.jan Iversen
added support for add_grammars macro Change-Id: I17955bd1534d9f43e1953691d985a18ee8241d38
2017-01-26gbuildtojson, added support for lex filesjan Iversen
added add_scanner macro Finalized the move around in gbuild-to-ide, to signal which generators are actively supported. Change-Id: I11699cd4380d49efc3b541abb7780b5136162433
2017-01-25-DOPTIMIZE appears to be unused, since foreverStephan Bergmann
Change-Id: I56c91974a27cf100bc0faa1b009f4bf6358b47f5
2017-01-25Minor loplugin:stringconstant improvementsStephan Bergmann
Change-Id: I0b39526c0f0854ddbb29e77ece303cf2bdd842c4
generated by cgit (git 2.34.1) at 2025-02-14 12:51:06 +0000