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 standard host triplet for mingw tools is is something like
x86_64-w64-mingw32 on debian and something like x86-64-w64-mingw32.shared for
mxe (http://mxe.cc). Detect windows packaging correctly for these build types.
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.
See bug 10053 for details. Without this, the package is only set correctly
for 32bit mingw.
Thanks Enrico for suggesting this fix and Shankar Giri Venkita Giri for
testing it.
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.
Since at least gcc 4.6 requires it, -std=c++11 has been passed to CPPFLAGS at 39717adfd. This was deemed necessary so that tests that use the preprocessor directly (AC_CHECK_HEADER) can have the right information.
It turns out that CPPFLAGS gets passed to objc compilation too (on Mac OS X) and this create compile-time errors.
Therefore we remove the -std flag from CPPFLAGS and re-add it to a separate variable cxx11_flags that is passed to LYX_CXX_USE_REGEX.
This amends commit e1938aa2, which introduced some logic
errors: regex would be enabled for gcc versions which have unusable
<regex> header.
The new code separates better special gcc handling from special C++11
handling and should be more readable.
* set -std=c++11 in AM_CPPFLAGS instead of AM_CXXFLAGS, since the
preprocessor uses this setting too.
* Before checking for header <regex>, set language to C++ and update
value of AM_CPPFLAGS too.
* Separate code that checks for regex in its own macro.
* now unknown compiler which have the <regex> header, will use std::regex in C++11 mode.
-Wno-deprecated-declarations is needed to avoid warnings about auto_ptr being obsolete.
The old code meant that the warnings would be suppressed for development builds, but active for release builds. The new code avoids that.
Only enable std::regex when the header <regex> is present (fix Mac OS X issue).
Remove support for concept checks. The page
https://gcc.gnu.org/onlinedocs/libstdc++/manual/concept_checking.html
says about concept checking:
Please note that the checks are based on the requirements in the
original C++ standard, many of which were relaxed in the C++11
standard and so valid C++11 code may be incorrectly rejected by the
concept checks. Additionally, some correct C++03 code might be
rejected by the concept checks, for example template argument types
may need to be complete when used in a template definition, rather
than at the point of instantiation. There are no plans to address
these shortcomings.
Therefore it seems reasonable to remove our support for this.
In general this would lead to an immediate runtime crash because the
runtime checks of libstdc++ change the layout of some STL objects.
Therefore, this will only work when the boost libraries have been
compiled with this same flag. At this time, it is not known whether
any linux distribution contains such libraries.
Fixes bug #9736.
When using -std=c++11, the cygwin compiler automatically defines
__STRICT_ANSI__ which is used as a guard for not declaring essential
unix standard calls such as setenv, popen, etc. As a result,
compilation stops with errors such as "xxxx has not been declared".
By undefining the guard, compilation succeeds and lyx works Ok.
Compiler that are known to support C++11 (gcc >= 4.3 and clang) are
now used in this mode by default. It is still possible to override
this choice using --(en|dis)able-cxx11.
Moreover, c++11 mode is detected from the compiler itself, not from
the use of --enable-cxx11. This allows to support compilers other
than gcc or clang.
Update INSTALL file accordingly and clean it a little bit.
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
This replaces tests for __cplusplus >= 201103L, which are wrong with gcc 4.6 and earlier. Indeed these versions of gcc define __cplusplus = 1.
Reference:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
We claim that gcc 4.x is needed in INSTALL, so it does not make sense to keep
this old stuff. Instead, I made configure output an error if gcc is too old.
The GNU libstdc++ that ships witch gcc 5 can be used with the same ABI as
older versions, or with a new ABI which is conformant to the C++11 standard.
LyX did not build if the latter was used:
https://kojipkgs.fedoraproject.org//work/tasks/1267/9651267/build.log
This is now fixed by detecting the ABI version and disabling the wrong forward
declarations. At the same time, STD_STRING_USES_COW is switched off for the
C++11 ABI version, because the std::basic_string implementation is now C++11
conformant. Since the GNU libstdc++ can also used by other compilers such as
clang, we must not test for the compiler version.
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)
The old detection did only work if CFLAGS contained -std=c++11, since ciso646
was only included for __cplusplus > 199711.
Thanks to Koernel for the cmake part.
The interface is now 100% unit tested, and the typedefs depend on the new
STD_STRING_USES_COW configuration variable. The only missing bit is to detect
clang and disable STD_STRING_USES_COW for clang.
Note that some mentions of svn remain in
* development/cmake/LyxPackaging.cmake
* development/LyX-Mac-binary-release.sh
* development/Win32/packaging/installer/settings.nsh
* 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.
Just some comments on the patch:
- The executable name has to match the information in Info.plist (development/MacOSX/Info.plist.in and CMakeLists.txt). The autoconf config/lyxinclude.m4 file has been modified to make it work with autotools.
- The process to build OS X bundle is to first add all the files to be included to the bundle when calling add_executable (src/CMakeLists.txt) and then by calling setting the source file property of each of these files (development/cmake/Install.cmake, l.14) so that the files are properly located into the bundle. This is also why Install.cmake has to be included two times in src/CMakeLists.txt (once to build the list of files, once to set the location of the list of files).
- in CMakeLists.txt there is a line
install(CODE "set(BU_CHMOD_BUNDLE_ITEMS 1)")
What it does is to fix the owner permissions within the bundle - this is necessary because some libraries are copied within the bundle and might be owned by root
- An empty qt.conf is included in the bundle so that QT does not try to link to other QT libraries (which will not be included in the bundle)
- In development/cmake/Install.cmake, some OS X specific files (*.sdef, qt.conf, *.icns) have to be included in the bundle
Benjamin
