Write dummy targets for included files, so the incremental build does
not break with "No rule to make target" if the included file is removed.
Change-Id: I23c4406c4d1db9a8a4a7f0ecfec1cfc9ad05028a
This reverts commit a042c2a6ab29011800de55fa382740be56c2d928.
A GNU make that understands native Win32 paths is required now anyway,
so revert this.
Conflicts:
idl/source/prj/database.cxx
Change-Id: I6eb77d4b02728269f8dc484444df0cabc8c29b3e
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Removed uses of fsys from database.cxx, command.cxx, module.cxx, svidl.cxx.
Also removed a lot of cruft from svidl.cxx and command.hxx; unused variables
and code relating to them, eg. variables aCxxFile, aHxxFile, aSrcFile, aODLFile.
Changed some Strings to OUStrings in svidl.cxx and command.hxx.
Change-Id: I708284f70435c8f65cdcfc954af43976e28b8c9d
Reviewed-on: https://gerrit.libreoffice.org/2935
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
Hello lo-devs,
this patch series removes a lot of unnecessary includes for the various
tools header. The patches without suffix should be applied to the core
repository, the .binfilter.patch suffix should be applied to the
binfilter repository. I've tested the build with the configuration
--enable-binfilter --enable-dbgutil --enable-debug, is this sufficient
or did I miss another important configuration, that enables some
conditional compiled code? I've only build this on linux-x86_64, but the
patch also touches some of the mac specific code like
fpicker/source/aqua/SalAquaFilePicker.mm so it would be maybe a good
idea to test this patch.
regards Marcel Metz
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
