INCLUDE is used by MSVC (http://msdn.microsoft.com/en-us/library/kezkeayy.aspx)
and make somehow (not sure why) exports the INCLUDE that gbuild uses,
which (again, not sure why) causes MSVC to report a misleading error about
incorrect argument. There actually does not appear to be any (unreasonably)
low path length limit on Windows.
Change-Id: I9329eb668f7a710ec69c8b5262b855f346ed01d2
The recent addition of Hebrew line breaking rules apparently does not
work with genbrk from ICU 4.6. Maybe we should just require 4.x (where x
is the first version where it is implemented) as minimum ICU version?
IMHO it would be better than this insane (and fragile) filtering...
Change-Id: Ia2adad3621fa7a2f319a07fb569b1f1c1eb6db7c
This allows us not to have cups during the build time of libreoffice.
Commit is inspired from patch from Dave Flogeras <dflogeras@gmail.com>.
Change-Id: I I32a14eb6e7bdd13de1a737d4798c852a830ae326
OOo used to use debug level this way:
0 is default for product build
1 for --enable-dbgutil
2 for environment variable debug=t, regardless of dbgutil setting
in LO these have now morphed into:
0 is default for product build
1 for environment variable debug=t
2 for --enable-dbgutil (at some intermediate stage in the past)
1 for --enable-dbgutil (today)
This has caused a lot of confusion and some things were not converted
properly, including a check in LinkTarget.mk.
Developers should use --enable-debug to get useful information,
including full debug info and assertions.
--enable-symbols is not intended for developers, but for people
who need their builds to be able to produce useful stack traces;
--enable-symbols is for example set unconditionally in the Fedora RPM
spec, and for this purpose disabling of inlining is not wanted.
It is unlikely that somebody wants symbols for only part of the build,
and consequently a different mechanism is used to set the corresponding
flags: they are set into global gb_LinkTarget_C{,XX}FLAGS.
So move the selective symbol feature back to --enable-debug.
(this substantially reverts db8df57acd)
It is done the same way the beanshell is handled.
Currently it can't be enabled by default as internal version has
patched-in debug interface.
We can choose two paths, rewrite the code to the new rhino debug
interface or just strip the current one out.
Change-Id: I48af18c635816db8269f13a649b62e9c454ee1e6
Maybe they'll be supported somewhen in the future, so do not hardcode
them out. Also, gb_DEBUG_C(XX)FLAGS are apparently common GCC options,
not platform-specific.
the argument given now can
- be 'all', meaning everything
- start with -, meaning not to enable symbols for that item
- end with /, meaning everything in that toplevel directory
- be a target of the form targettype_name, e.g. Library_swui
Note that there is no ordering and removal takes precedence.
- move using optimization, symbols (i.e. debug) and environment
cflags/cxxflags into one place
- --enable-dbgutils is independent from --enable-debug, and thus
also --enable-symbols, so it should not set debuglevel
- setting -g flag is controlled by --enable-symbols, not --enable-debug,
so it should be used also for selective -g enabling
- setting debug flags depending on debuglevel being 2 is certainly wrong
- do not let environment cflags/cxxflags disable optimization/symbols flags
completely, if one wants, it's possible to explicitly specify e.g. -g0,
but the current way does not make it easily possible to specify e.g.
-fcolor-diagnostics
- do not set debug flag globally now that it can be done selectively
with this you can now do:
./autogen.sh --enable-debug="sw sc"
and your build will have debug version of the libraries sw and sc, but a
non-debug build elsewhere. This currently only works for libraries. It would be
also possible to extend that to excutables, but that would need explicit in the
enable-debug switch then:
./autogen.sh --enable-debug="Library/sw Library/sc Executable/mkunroll"
so I dont know if it is worth it.
$(file is a new function that landed in gnu-make cvs
it allow to write a makefile variable directly into a file
bypassing the usual command line size limitiation
The idea is to use libo_MINGW_CHECK_DLL for libs that must be available
(typically that would be the "main" library, e.g., libxml2 or libcurl)
and libo_MINGW_TRY_DLL for possible dependencies (that may not be the
same on different systems). All further references to the dlls are
exclusively through the configured variables or defines set from these
variables (e.g., instead of hardcoding libxml2-2.dll, use
$(MINGW_LIBXML2_DLL)).
The macros are documented in m4/mingw.m4 .
Files that must be changed when adding a new dll:
* configure.in
* config_host.mk.in
* external/mingw-dlls/makefile.mk
* scp2/source/ooo/makefile.mk
* scp2/source/ooo/mingw_dlls.scp
Since OString already has a ctor accepting const char*, I cannot
find out a way to distinguish string literals other than using
a template, otherwise const char* somehow takes precedence
(all of gcc, clang, msvc). But the template requires
the Substitution Is Not A Failure Idiom to actually create
only wanted instances. And the compiler can try evaluate
the OString ctor as a possibility when comparing an int to
an anonymous enum, and anonymous enum as a type without linkage
cannot be a template argument before C++11. SFINAE should still
work, but not with gcc older than 4.0.2 (which we right now
use only on macs). So for that case disable the string literal
ctors, which means macs will have one extra strlen call,
and also that embedded \0's in string literals will be
inconsistent. The tiny performance problem shouldn't matter that
much and will eventually go away, the \0 problem should not
matter, since before string literal ctors were introduced
\0's had not been included anyway unless RTL_CONSTASCII_STRINGPARAM
was used. So we should be safe and when removing the CONSTASCII
macros \0 cases should be handled by explicitly mentioning
the length.
