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)
It works with gcc >= 4.9.0 and clang (with libc++ or gcc libstdc++ from gcc
>= 4.9.0). The MSVC parg is missing, because I cannot test it, and the
autotools build still link against boost::regex even if it is not needed, but
I don't know how to fix that.
As discussed on the list. We don't need it anymore, either we have a modern
compiler that supports C++11, or we fall back to boost. I kept and adjusted
the regex #define, since we cannot use std regex completely yet.
If we compile in C++11 mode, do not use the boost replacements for bind,
functional and shared_ptr. regex is excluded, since it misses match_partial, and
gcc does not provide a usable one in versions less than 4.9.0.
I also removed the #define for match_partial, since this is dangerous. Now you
get a compile error instead of subtle runtime differences.
The option --enable-qt5 allows configuring for Qt5. The default is Qt4.
Nothing special is done with respect to Qt4, apart from pulling in the
correct libraries. Indeed, other than the core and gui libraries, now
also the concurrent and widgets libraries are needed.
This option is going to be mandatory starting with automake 2.0.
LyX is able to use this since version 2.1, but it turns out that it is
badly implemented in versions of automake older than 1.14.
We rely on some (undocumented) symbol to detect automake 1.14 and
use the subdirs-objects option in this case.
For more details, see:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181023.html
Making everything work with autotools required making a copy of two
files from support/tests. It seems that we should not point to source files
that are handled by another Makefile.am.
The problems the comments in the build systems refer to seem to have been
fixed for years. [1] says the checks in libstdc++ have been improved, and
all supported FreeBSD versions enable wchar_t support unconditionally in
libstdc++. Additionally, this needlessly impacts FreeBSD when libc++ is used
instead of libstdc++.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.freebsd_wchar
The reason for adding this option is to kill a warning with automake 1.14. However, the "make distclean" target does not work with the subdir-objects options for older versions of automake. To still allow older versions of automake, we remove this option and live with the warning when using automake 1.14.
This reverts commit 03343bd4e6.
Make sure that the configure script only checks features using the C++ compiler.
Also get rid of our last C files, since they are not compiled nor distributed anyway.
Using autotools, the availability of putenv is not checked, so
the macro HAVE_PUTENV is not defined and compiling stops with
the error "No environment-setting function has been defined."
Thus, also check for putenv.
* build-type=profiling implies -fno-omit-frame-pointer in gcc. This allows sysprof to yield proper call trees
* remove --enable-grpof option (the build type is enough)
* remove --with-frontend option since we have only one frontend. Move stuff around and generally simplify the Qt detection code
* do not check for bc anymore.
* Update README.
The current code is not able to unset an environment variable, only to set it to an empty value. This patch refactors a bit the Message class and uses a new EnvChanger helper class that allows to change temporarily an environment variable and that is able to unset variables if needed.
The patch also adds new functions hasEnv and unsetEnv in environment.cpp.
Open issues:
* there may be systems where unsetenv is not available and putenv("name=") does not do the right thing;
* unsetenv may lead to leaks on some platforms.
* when using unsetenv, we may need to remove strings from the internal map that setEnv uses.
The previous scheme of loading all possible translations and checking whether the work
is a bit too much "brute force" and causes problems on Mac OS X (documents loaded
with the wrong language).
In the new scheme, autotools install a file lib/installed_translations that contains a list of installed languages (the .gmo files that got installed). This file is read
in Languages::readInstalledTranslations and allows to set the translated() property
of each language.
* add proper INSTALL_POSIX conditional for makefiles
* move all the code to Makefile.am
* rename lyx.desktop to lyx.desptop.in and add proper tags to allow handling of program_suffix.
* add code to install desktop entry and icons under the proper name.
I did not touch scons and cmake, I hope it was not necessary.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40531 a592a061-630c-0410-9148-cb99ea01b6c8
