Was not removing definition flags (-D...) from cxx flags,
when the definition flag was last in the list returned from
wx-config.
--HG--
extra : rebase_source : 3452c52b92717f181e902abef38c1e2718ce3b27
Was not removing definition flags (-D...) from cxx flags,
when the definition flag was last in the list returned from
wx-config.
--HG--
extra : rebase_source : 3452c52b92717f181e902abef38c1e2718ce3b27
Synced from KDE svn: pkg_check_modules() and pkg_search_module() now
both support a QUIET keyword. When given, no messages will be printed (except the REQUIRED ones)
This also fixes#10469 (confusing output of FindLibXml2.cmake)
Alex
After configuring CMakeFiles/CMake<lang>Compiler.cmake in the build tree
the second time (to store ABI information), include it immediately.
This allows any logic and settings in the compiler information files to
be used without duplicating it in CMakeDetermineCompilerABI.cmake.
The change in commit "Use Fortran ABI detection results conservatively"
(2010-05-05) needs this to use the same logic to set CMAKE_SIZEOF_VOID_P
during first and later runs of CMake.
We set CMAKE_Fortran_SIZEOF_DATA_PTR in the Fortran compiler information
file after detecting the compiler ABI. However, since Fortran does not
really have pointers, the preprocessor-based detection is unreliable.
The result is needed to set CMAKE_SIZEOF_VOID_P only for Fortran-only
projects because the value can come from C or C++ compilers otherwise.
Therefore when CMAKE_SIZEOF_VOID_P is available from another language we
should defer to it.
The expectation of users of the MSVC60, MSVC70, MSVC71, MSVC80, MSVC90
and the new MSVC10 variables is that at most one of them will be set
for any given build tree. This change enforces that expectation for
build trees using Makefile generators. It also fixes the one mismatch
in that expectation to be found in the Visual Studio generator world:
previously, the VS 7.1 generator would set *both* MSVC70 and MSVC71;
now, it only sets MSVC71.
With these changes, user expectations are now met, and the recently
introduced CheckCompilerRelatedVariables test should pass everywhere.
This means that the user no longer sees this value _but_ this is backwards compatible because setting JASPER_LIBRARIES had no effect previously because we would override it using set()
As reported on the mailing list, find_path/file/library/program() basically don't work
at all if CMAKE_FIND_ROOT_PATH is set and searching in the host system directories
is disabled. This patch adds /include, /lib and /bin to the search directories, so they
will be appended to CMAKE_FIND_ROOT_PATH so this will work for the "Generic" platform (embedded
systems without OS)
Alex
(I accidentially removed ExternalProject.cmake from git by doing
mv ExternalProject.cmake ExternalProject.cmake.save
git checkout master
which I hoped would basically do a revert as it does with svn and cvs, but it
deleted the file from git)
Alex
Detect the runtime linker's search path and add to the compile time
linker's search path. This is needed because OpenBSD's static linker
does not search for shared library dependencies in the same places as
the runtime linker.
Teach compiler identification to support values such as
export CC='gcc -g -O2'
by separating the arguments on spaces. We already do this for the
values of CFLAGS, CXXFLAGS, and FFLAGS.
This allows the user not to link to the common libraries,
which are regularly required. The user must specify all
libraries that he does want to link in the find_package
line (png tiff jpeg zlib regex expat).
--HG--
extra : rebase_source : df29f96c957600629a34a1c5fafb8b3d6f274e22
Allow the user to set the CMake variable CTEST_COST_DATA_FILE, which will be used to store the cost data from test runs. If not set, defaults to the original location in the build tree Testing/Temporary dir.
Commit "Modernize GNU compiler info on Windows" (2009-12-02) reorganized
GNU flags on Windows but let -fPIC slip through for compilation of
objects in shared libraries. While this flag is valid on most GNU
compiler platforms we need to suppress it in Windows-GNU.cmake just as
we already do in CYGWIN-GNU.cmake.
This modifies the behavior of PYTHON_WRITE_MODULES_HEADER, should be backwards
compatible. Also marked a couple of the variables generated by adding Python
modules as advanced.
PathScale Fortran mangles module symbols as "MY_SUB.in.MY_MODULE" and
also requires "my_module_" when the module is imported. We cannot
provide the symbol with ".in." mangling so we should not provide
"my_module_" because it would duplicate the one in the Fortran-provided
object file.
Commit "FortranCInterface: Fix PathScale detection" (2010-01-22) already
made the same fix for the non-underscore module case.
In the CTest module we previously warned if the source directory did not
contain known version control directories. The message was:
"CTest cannot determine repository type. Please set UPDATE_TYPE
to 'cvs' or 'svn'. CTest update will not work."
This was confusing when building sources from a tarball. Furthermore,
we now support many more version control tools. This feature is now
mature enough that the warning causes confusion more than it provides
real help. We simply remove it.
The compiler documents symbols _DF_VERSION_ and _VF_VERSION_ but they do
not seem to be available to the preprocessor. Instead we add a vendor
query table entry for Compaq. Running "f90 -what" produces
Compaq Visual Fortran Optimizing Compiler Version ...
This clearly identifies the compiler.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" and also
requires "mymodule_" when the module is imported. We cannot provide the
symbol with ".in." mangling so we should not provide "mymodule_" because
it would duplicate the one in the Fortran-provided object file.
In commit "use export all symbols on cygwin" (2003-01-21) we started
passing -Wl,--export-all-symbols when linking shared libraries. Now
cygwin exports all symbols automatically if no symbols are explicitly
exported. When symbols are explicitly exported we want to honor that
narrow interface. Therefore this flag should not be passed.
Change based on patch from issue #10122.
The variable should contain the name of a library needed to link the
symbol equivalent to dlopen. On Cygwin no special library is needed,
and certainly not "gdi32".
Change based on patch from issue #10122.
After discussing with Brad and Clinton:
-the namespace for the imported targets is now "Qt4::", tested with Makefiles, Visual Studio and XCode projects
-the imported targets are always created
-if QT_USE_IMPORTED_TARGETS is set to TRUE (it defaults to FALSE), the QT_QTFOO_LIBRARY variables are set to point to these imported
targets, otherwise the old behaviour is used.
-on OSX if Qt has been found as framework, disable QT_USE_IMPORTED_TARGETS, since cmake doesn't handle the framework directory as location of the library correctly
Alex
-set the type of the IMPORTED libraries to UNKNOWN, this way also on Windows
only the "LOCATION" property has to be set
-the if() around the SET(QT_${basename}_FOUND 1) was useless (always true)
-the mapping of the configuration types DEBUG and PROFILE did not belong here
Alex
This commit syncs FindQt4.cmake again with KDEs version.
Now for every Qt library an imported target with the name
Qt4ImportedTarget__<LIBNAME> is created.
This way we can now finally handle the release and debug versions of the Qt
libraries correctly.
Also, if a Qt-using project A installs a file with exported targets, these
targets now depend on the imported Qt targets, e.g.
Qt4ImportedTarget__QtCore. The location of QtCore is then resolved at
buildtime of project B, which uses the exported targets from project A.
Before this patch the full path to the QtCore on the original build machine
of project A was stored, so this had to match the directory layout on the
build machine for project B.
Alex
While Cygwin supports linking directly to .dll files, the behavior is
now discouraged. All Cygwin packages now provide import libraries of
the form lib*.dll.a and CMake has built the import libraries for years.
We believe it is now safe to stop explicitly searching for .dll files
because their import libraries will always be available when the
corresponding header files are available. Users can always set
find_library cache entries to point at a .dll file by hand if they
really must use one.
Change based on patch from issue #10122.
Bill Hoffman
Alex Neundorf
Miguel A. Figueroa-Villanueva
Brad King
David Cole
C. Bergström
Kovarththanan Rajaratnam
Eric NOULARD
Clinton Stimpson
Chuck Atkins
Michael Wild
David Partyka
Zach Mullen
Marcus Hanwell
James Bigler