This allows to fix distclean properly, since we know that
subdir-objects is used. When it is the case, it is not a good idea for
a Makefile to use a source file which is under the control of another
one. This could not be made to work work with old automake versions
(<1.14).
Therefore we refer directly to object files in Makefile.am instead of
source files. The actually leads to less compilation in tex2lyx.
Update the code here and there to remove compatibility hacks. Update
documentation.
Re-enable the layout test and fix the Length test, which was ovewriting
memory in test_inPixels() because lyxrc did not had a correct layout.
Now configure searches in this order
1. system-installed library
2. code bundled with LyX
If --with-included-mythes or if no mythes library is installed, then
the script selects the bundled version. There should be no cases
leading to error message.
The configure code suggests that the default for
--with-included-(iconv|zlib|hunspell) is "yes", which is wrong: by
default is indeed to use the system libraries.
Change the MyThes detection to use the system version by default.
Also add to the verison information a line which lists the bundled libraries.
Boost.Signals is deprecated. This fixes bug #9943.
The only thing left to do is to rewrite (or get rid of) the boost -mt test
in config/lyxinclude.m4 not to use signals anymore.
As discussed on the list. If no C++11 compiler is found configuration stops
with an error. There are now unneeded parts of boost, the will be removed in
a second commit.
The Reproducible Builds effort (https://wiki.debian.org/ReproducibleBuilds) in Debian (at least) means that 'ar' is built in deterministic mode as default: all timestamps are set to 0.
This is not compatible with the use of the 'u' flag, and therefore ARFLAGS has to be changed from 'cru' to 'cr'.
This gets rid of the harmless but annoying warning
ar: `u' modifier ignored since `D' is the default (see `U')
Use the standard way to check for the resource compiler, as e.g.
libtool does it: AC_CHECK_TOOL does already provide some cross compiling
magic, and we do also get an error now at configure time if windres is not
found.
The windres program is typically not called windres for cross compilation.
Now you can call configure with the argument
WINDRES=x86_64-w64-mingw32-windres
in order to use the windres program on a standard debian installation.
The included iconv should not be used on Linux or OS X, but (depending on
local configuration) it might be needed for crosscompiling a mingw target
from Linux. Now the user can choose whether to use the included iconv or not.
cmake does already support that.
eilseq.m4 was taken from the original libiconv 1.14 package.
On mingw-w64, long long (64bit wide) is larger than long (32bit wide).
Therefore we need some more specializations for string, docstring,
otextstream and << overloaded ostream functions. The configuration code
is by me, the source code changes by Shankar Giri Venkita Giri (bug 10053).
The included zlib should not be used on Linux or OS X, but (depending on
local configuration) it might be needed for crosscompiling a mingw target
from Linux. Now the user can choose whether to use the included zlib or not.
cmake does already support that.
zconf.h.in was taken from the original zlib 1.2.8 package. The generation of
zconf.h was made equivalent to the one generated by cmake.
The new 3rdparty libraries are not added to the autotools build system, so
that they appear in the source package. They cannot be compiled yet with
autotools (although this would make sense for cross compilation with mingw),
but adding configure support for enabling/disabling these like we do for
boost is a bit more work, so I did not do it for now. Nevertheless, the
three new Makefile.am are already prepared for compilation.
Thanks to Kornel we do now have the infrastructure for running dedicated
export tests. This is the first one, showing a language nesting bug which is
already in 2.1. It is inverted for now, but this will hopefully change soon.
This replaces commit 329eae56 with a better solution. Indeed, while
__cpluplus is useless with g++ 4.[3-6] because its value is always 1,
these compilers define __GXX_EXPERIMENTAL_CXX0X__ when "-std c++0x" is used.
Therefore the code now relies on both macros to detect C++11 mode
instead of setting it when --enable-cxx11 is used.
Also, use pure c++ mode instead of gnu++ extensions on gcc
Some distros may use target-specific prefix for ar program (like
x86_64-pc-linux-gnu-ar). Automake can handle that since version 1.12.
Since we still support automake 1.8 (not that it is really crucial,
but ubuntu 12.04 ships with automake 1.11.3), make the code
conditional.
Update a bit the gitignore files (automake creates some files in config/).
Based on a patch from Nikolay Orlyuk <virkony@gmail.com>.
A new macro adapted from AM_PROG_PYTHON is defined. It does the dual version testing for python 2 and python 3. The rest of the functionnality of AM_PROG_PYTHON has been stripped off.
Once our special macro has been invoked, we use the usual AM_PROG_PYTHON.
Now CXXFLAGS is left alone by autoconf: only the user can override it.
Properly set -g and -O options, which were overriden.
Try to put the arguments in a more reasonable ordering.
Get rid of some old useless compiler checking code
Do not touch CXXFLAGS and friends, only the AM_* version
Let the gcc-related options for latest known version be the default (assume they will still be fine in future versions)
Try to take clang in account in a better way (to be continued):
* use proper option for C++11,
* use -Wno-deprecated-register in this case because Qt has a lot of these
* define version as being clang for internal testing (there is no real way to get the clang version)
