[cmake-developers] [CMake 0014465]: Under windows, the filename of the file currently compiled is echoed
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14465 == Reported By:ycollet Assigned To: == Project:CMake Issue ID: 14465 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-10-09 03:56 EDT Last Modified: 2013-10-09 03:56 EDT == Summary:Under windows, the filename of the file currently compiled is echoed Description: Under windows, the filename of the file currently compiled is echoed. For example, under windows visual studio 2008 dos console, we have: ... [ 95%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/TestSuites/VarnamesTestSuite.cpp.obj VarnamesTestSuite.cpp [ 95%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/TestSuites/DataTypesTestSuite.cpp.obj DataTypesTestSuite.cpp [ 96%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/UserConstraints/Exceptions.cpp.obj Exceptions.cpp [ 96%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/UserConstraints/General.cpp.obj General.cpp [ 97%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/General.cpp.objGeneral.cpp [ 97%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/PurePython/General.cpp.obj General.cpp [ 98%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/ReservoirUnitTest.cpp.obj ReservoirUnitTest.cpp Under linux, we have: [ 95%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/TestSuites/VarnamesTestSuite.cpp.obj [ 95%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/TestSuites/DataTypesTestSuite.cpp.obj [ 96%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/UserConstraints/Exceptions.cpp.obj [ 96%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/UserConstraints/General.cpp.obj [ 97%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/General.cpp.objGeneral.cpp [ 97%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/UnitTest/PurePython/General.cpp.obj [ 98%] Building CXX object src/RiskManagerTest/CMakeFiles/RiskManagerTesting.dir/ReservoirUnitTest.cpp.obj == Issue History Date ModifiedUsername FieldChange == 2013-10-09 03:56 ycolletNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014467]: WiX Generator: Move the TARGETDIR directory from directories.wxs to the main template
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14467 == Reported By:Ådne Hovda Assigned To: == Project:CMake Issue ID: 14467 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-10-09 05:46 EDT Last Modified: 2013-10-09 05:46 EDT == Summary:WiX Generator: Move the TARGETDIR directory from directories.wxs to the main template Description: Move the main Directory Id=TARGETDIR Name=SourceDir / tag including the program files folder entry to the main.wxs file, leaving only INSTALL_ROOT and below in directories.wxs. That makes it possible to override the install location using a custom template (e.g. C:\program files\company\product). Selecting the correct ProgramFilesFolder/ProgramFiles64Folder should be handled by a new include variable and a new ?if ? block. Here are some excerpts to (hopefully) clarify my ideas: cpack_variables.wxi: ?define CPACK_WIX_ARCH=x86 ? WIX.template.in: ?if $(var.CPACK_WIX_ARCH) = x86 ? ?define Win64 = no ? ?define SystemFolder = SystemFolder ? ?define CAQuietExec = CAQuietExec ? ?define ProgramFilesFolder = ProgramFilesFolder ? ?define ExecSecureObjects = ExecSecureObjects ? ?else? ?define Win64 = yes ? ?define SystemFolder = System64Folder ? ?define CAQuietExec = CAQuietExec64 ? ?define ProgramFilesFolder = ProgramFiles64Folder ? ?define ExecSecureObjects = ExecSecureObjects_64 ? ?endif? Directory Id=TARGETDIR Name=SourceDir Directory Id=$(var.ProgramFilesFolder) DirectoryRef Id=INSTALL_ROOT / /Directory /Directory directories.wxs: Directory Id=INSTALL_ROOT Name=MyProduct Directory Id=bin Name=bin/ Directory Id=include Name=include/ Directory Id=lib Name=lib/ Directory Id=share Name=share Directory Id=share.man Name=man Directory Id=share.man.man3 Name=man3/ /Directory /Directory /Directory == Issue History Date ModifiedUsername FieldChange == 2013-10-09 05:46 Ådne Hovda New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014468]: WiX: Include extra .wxs and/or .wixlib files
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14468 == Reported By:Ådne Hovda Assigned To: == Project:CMake Issue ID: 14468 Category: CPack Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-10-09 05:54 EDT Last Modified: 2013-10-09 05:54 EDT == Summary:WiX: Include extra .wxs and/or .wixlib files Description: Make it possible to specify a list of extra .wxs and/or .wixlib files to be included when building the installer. == Issue History Date ModifiedUsername FieldChange == 2013-10-09 05:54 Ådne Hovda New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FLAGS on Darwin and custom languages
On 10/08/2013 07:12 PM, Vittorio Giovara wrote:
I noticed that in 2.8.11 under OSX CMake adds -F/Library/Frameworks in
every kind of FLAGS rule, for any language.
The flag is hard-coded in the C++-implemented generator code under
the assumption that all compilers on APPLE support -F. The -F
option appears in a few places literally in the C++ source:
$ git grep -- '-F' v2.8.11 -- 'Source/*.cxx'
v2.8.11:Source/cmCTest.cxx: if(this-CheckArgument(arg, -F))
v2.8.11:Source/cmLocalGenerator.cxx: -F
this-Convert(frameworkDir.c_str(),
v2.8.11:Source/cmLocalGenerator.cxx:frameworkPath += -F;
v2.8.11:Source/cmMakefileTargetGenerator.cxx:flags += -F;
v2.8.11:Source/cmQtAutomoc.cxx:this-MocIncludes.push_back(-F);
v2.8.11:Source/ctest.cxx: {-F, Enable failover., This option allows ctest
to resume a test
Take a look at the occurrences in cmLocalGenerator.cxx and in
cmMakefileTargetGenerator.cxx. The hard-coded -F should be
replaced with a platform information variable lookup that depends
on the language. One could introduce a new variable such as
CMAKE_LANG_FRAMEWORK_SEARCH_FLAG
and set it to -F in the upstream platform files but not in your
pascal file.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] WiX generator and generic file IDs
Hi I've taken the CPack WiX generator for a spin and it covers most of our requirements, but I have a few suggestions for improvement: 1. Make it possible to specify a list of extra .wxs files to be included when building the installer. 2. Automatically generated IDs for File /, Directory / and Component / tags, DIR_ID_1, FILE_ID_1, COMP_ID_1, are non-deterministic and that makes it impossible to reference those objects by ID from other parts of the WiX code, to execute an installed binary, add service config and firewall exceptions, for example. So, instead compose the ID by concatenating the relative path from INSTALL_ROOT and the file name, using some valid delimiter, a combination which should always be unique within one installer. A file and its component should simply share ID. 3. Move the main Directory Id=TARGETDIR Name=SourceDir / tag including the program files folder entry to the main.wxs file, leaving only INSTALL_ROOT and below in directories.wxs. That makes it easier to override the install location with a custom template. Selecting the correct ProgramFilesFolder/ProgramFiles64Folder should be handled by a new include variable and a new ?if ? block. Here are some excerpts to (hopefully) clarify my ideas: cpack_variables.wxi: ?define CPACK_WIX_ARCH=x86 ? WIX.template.in: ?if $(var.CPACK_WIX_ARCH) = x86 ? ?define Win64 = no ? ?define SystemFolder = SystemFolder ? ?define CAQuietExec = CAQuietExec ? ?define ProgramFilesFolder = ProgramFilesFolder ? ?define ExecSecureObjects = ExecSecureObjects ? ?else? ?define Win64 = yes ? ?define SystemFolder = System64Folder ? ?define CAQuietExec = CAQuietExec64 ? ?define ProgramFilesFolder = ProgramFiles64Folder ? ?define ExecSecureObjects = ExecSecureObjects_64 ? ?endif? Directory Id=TARGETDIR Name=SourceDir Directory Id=$(var.ProgramFilesFolder) DirectoryRef Id=INSTALL_ROOT / /Directory /Directory directories.wxs: Directory Id=INSTALL_ROOT Name=MyProduct Directory Id=bin Name=bin/ Directory Id=include Name=include/ Directory Id=lib Name=lib/ Directory Id=share Name=share Directory Id=share.man Name=man Directory Id=share.man.man3 Name=man3/ /Directory /Directory /Directory files.wxs: DirectoryRef Id=bin Component Id=bin.prog1.exe Guid=* Win64=$(var.Win64) File Id=bin.prog1.exe Source=bin/prog1.exe KeyPath=yes/ /Component /DirectoryRef DirectoryRef Id=include Component Id=include.lib1.h Guid=* Win64=$(var.Win64) File Id=include.lib1.h Source=include/lib1.h KeyPath=yes/ /Component /DirectoryRef DirectoryRef Id=lib Component Id=lib.lib1.lib Guid=* Win64=$(var.Win64) File Id=lib.lib1.lib Source=lib/lib1.lib KeyPath=yes/ /Component /DirectoryRef DirectoryRef Id=share.man.man3 Component Id=share.man.man3.prog.3 Guid=* Win64=$(var.Win64) File Id=share.man.man3.prog.3 Source=share/man/man3/prog.3 KeyPath=yes/ /Component /DirectoryRef -- Best regards, Ådne Hovda -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014470]: CPACK_ZIP_COMPONENT_INSTALL does not work
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14470 == Reported By:Bjoern Thiel Assigned To: == Project:CMake Issue ID: 14470 Category: CPack Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-10-09 10:12 EDT Last Modified: 2013-10-09 10:12 EDT == Summary:CPACK_ZIP_COMPONENT_INSTALL does not work Description: One needs to use CPACK_ARCHIVE_COMPONENT_INSTALL instead as the corresponding SupportsComponentInstallation() method is missing in the cmCPackZIPGenerator class. Please fix this for all CPack generators inheriting from cmCPackArchiveGenerator or at least clarify the documentation. == Issue History Date ModifiedUsername FieldChange == 2013-10-09 10:12 Bjoern Thiel New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WiX generator and generic file IDs
On 10/09/2013 05:03 AM, Ådne Hovda wrote: I've taken the CPack WiX generator for a spin and it covers most of our requirements, but I have a few suggestions for improvement: FYI, the WiX generator is a contributed feature: git log -- Source/CPack/WiX Modules/CPackWIX.cmake Modules/WIX.template.in and currently has no upstream maintainer. If anyone wishes to volunteer as a maintainer, please look here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote:
Steve, please explain your proposal in more detail. How does the list of
requested features get mapped to the proper -std=cxx11 or equivalent flag?
In my branch that is determined by which list the feature appears in. Eg,
from GNU-CXX.cmake:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
generalized_lambda_capture
return_type_deduction
)
endif()
Then, in the implementation of target_compiler_feature,
list(FIND CMAKE_CXX11_COMPILER_FEATURES ${FEATURE_NAME} needs11)
list(FIND CMAKE_CXX14_COMPILER_FEATURES ${FEATURE_NAME} needs14)
list(FIND CMAKE_CXX17_COMPILER_FEATURES ${FEATURE_NAME} needs17)
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
Then, in cmLocalGenerator:
const char *standard = target-GetProperty(CXX_STANDARD);
std::string compile_option =
CMAKE_CXX + std::string(standard) + _STANDARD_COMPILE_OPTION;
if (const char *opt =
target-GetMakefile()-GetDefinition(compile_option.c_str()))
{
this-AppendFlags(flags, opt);
}
This is where I have an open question in the branch:
# TODO: Gnu extensions supported by -std=gnu++98 ?
# And others.
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Dialect-Options.html#C-Dialect-Options
# TODO: Maybe instead we should define like this:
#
# set(CMAKE_C_COMPILE_OPTIONS_STD -std=)
# set(CMAKE_CXX_COMPILE_OPTIONS_STD -std=)
#
# so that the CXX_STANDARD target property can contain the argument string
# (including possibly extensions).
# That might call for some kind of mapping though because XL uses different
# values (eg extended0x)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9
# AND VERSION_LESS 4.11 # Speculative
)
set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y)
endif()
# if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.11) # Speculative
# set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14)
# endif()
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: Steve, Eike, Now that 2.8.12 is tagged I'd like to revive the work to support C++11 features. I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/09/2013 10:51 AM, Stephen Kelly wrote: I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Fantastic, thanks! -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/09/2013 10:44 AM, Stephen Kelly wrote:
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
This assumes a linear ordering among standards, which is true for the
actual standards, but may not be true for the compiler feature levels.
For example, the GNU compiler has a gnu variant branching off from
each standard level.
This is where I have an open question in the branch:
# TODO: Gnu extensions supported by -std=gnu++98 ?
# And others.
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Dialect-Options.html#C-Dialect-Options
Perhaps each feature can map to the minimum standard spec flag
it needs:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX_FEATURE_FLAG_final -std=c++11)
set(CMAKE_CXX_FEATURE_FLAG_override -std=c++11)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
set(CMAKE_CXX_FEATURE_FLAG_generalized_lambda_capture -std=c++1y)
set(CMAKE_CXX_FEATURE_FLAG_return_type_deduction -std=c++1y)
endif()
Then have a graph of flags subsuming others:
set(CMAKE_CXX_STANDARD_SUBSUMES_-std=c++1y -std=c++11)
Then from the needed features, their corresponding flags,
and the subsume graph, compute the possible flags.
Then provide a way for the project and/or user to specify
their preferred flag and use it or error if it is not one
of those possible. If no preference is given, choose the
oldest flag.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014471]: -T switch with Intel Compiler does not set CMAKE_CXX_COMPILER properly
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14471 == Reported By:Christian Weigel Assigned To: == Project:CMake Issue ID: 14471 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-10-09 11:37 EDT Last Modified: 2013-10-09 11:37 EDT == Summary:-T switch with Intel Compiler does not set CMAKE_CXX_COMPILER properly Description: When specifying the Intel Compiler platform toolset CMAKE_CXX_COMPILER is still set to the MSVC compiler when cmake is run inside the intel compiler command prompt. Steps to Reproduce: Start Intel Compiler command prompt (e.g. C:\Windows\SysWOW64\cmd.exe /E:ON /V:ON /K C:\Program Files (x86)\Intel\Composer XE 2013\bin\ipsxe-comp-vars.bat ia32 vs2010) run cmake -TIntel C++ Compiler XE 13.0 src_path Additional Information: when verbosing CMAKE_CXX_COMPILER the output of the first run is: -- Building for: Visual Studio 10 -- The C compiler identification is Intel 13.1.0.20130607 -- The CXX compiler identification is Intel 13.1.0.20130607 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 -- Check for working CXX compiler using: Visual Studio 10 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- CMAKE_CXX_COMPILER=c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin /cl.exe == Issue History Date ModifiedUsername FieldChange == 2013-10-09 11:37 Christian WeigelNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WiX generator and generic file IDs
I think I'd like to sign up as maintainer for the WiX generator unless someone else wants to volunteer. I probably won't put as much time into it as it would deserve so if there is someone else who wants to work on it instead I would not mind either. Nils On 09.10.2013 16:40, Brad King wrote: On 10/09/2013 05:03 AM, Ådne Hovda wrote: I've taken the CPack WiX generator for a spin and it covers most of our requirements, but I have a few suggestions for improvement: FYI, the WiX generator is a contributed feature: git log -- Source/CPack/WiX Modules/CPackWIX.cmake Modules/WIX.template.in and currently has no upstream maintainer. If anyone wishes to volunteer as a maintainer, please look here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer -Brad -- Powered bywww.kitware.com Visit other Kitware open-source projects athttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at:http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WiX generator and generic file IDs
On 10/09/2013 12:56 PM, Nils Gladitz wrote: I think I'd like to sign up as maintainer for the WiX generator Wonderful, thanks! unless someone else wants to volunteer. I probably won't put as much time into it as it would deserve so if there is someone else who wants to work on it instead I would not mind either. We can have more than one as long as communication takes place. You've already followed most of the steps here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer I just marked your issue tracker account as a developer. Now just follow the Git setup steps here: http://www.cmake.org/Wiki/CMake/Git/Develop#Setup to get push access. Read the rest of that page to see how to push and merge topics. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014472]: RPM Generator w/ component install and all comps in one package - name property has ALL_COMPONENTS_IN_ONE
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14472
==
Reported By:Lee Graber
Assigned To:
==
Project:CMake
Issue ID: 14472
Category: CPack
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2013-10-09 13:32 EDT
Last Modified: 2013-10-09 13:32 EDT
==
Summary:RPM Generator w/ component install and all comps in
one package - name property has ALL_COMPONENTS_IN_ONE
Description:
I am producing an RPM which I want to only contain certain installed
components. I have set the following flags:
...
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_COMPONENTS_ALL My list of components)
set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
...
As per CPackRPM.cmake:
# Are we packaging components ?
if(CPACK_RPM_PACKAGE_COMPONENT)
set(CPACK_RPM_PACKAGE_COMPONENT_PART_NAME -${CPACK_RPM_PACKAGE_COMPONENT})
set(CPACK_RPM_PACKAGE_COMPONENT_PART_PATH /${CPACK_RPM_PACKAGE_COMPONENT})
set(WDIR
${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}/${CPACK_RPM_PACKAGE_COMPONENT})
else()
set(CPACK_RPM_PACKAGE_COMPONENT_PART_NAME )
set(CPACK_RPM_PACKAGE_COMPONENT_PART_PATH )
set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME})
endif()
and then later:
Name:
\@CPACK_RPM_PACKAGE_NAME\@\@CPACK_RPM_PACKAGE_COMPONENT_PART_NAME\@
I either need a way to override this, or, if CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE
is set, then the part_name should be blank as it would be for a non-component
install.
Steps to Reproduce:
Create a package using the following flags:
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_COMPONENTS_ALL My list of components)
set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
either look at the generated spec or use rpm -qpi rpm file to see the name
generated
Additional Information:
This name is the name that users have to use to uninstall the rpm so it is
important that it not be random like this. It makes discovery much more
difficult. Since it is in the cmake file, I workaround this by changing the
behavior myself but this appears to be the wrong behavior.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-10-09 13:32 Lee Graber New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Am Mittwoch, 9. Oktober 2013, 16:51:42 schrieb Stephen Kelly: Brad King wrote: Steve, Eike, Now that 2.8.12 is tagged I'd like to revive the work to support C++11 features. I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. The idea that we agreed upon (or basically: that Steve proposed and which I didn't fully understand until today) is that there will be a list of supported features for every compiler and version. Usually CMake will just use that list when it goes to determine if it could satisfy the requested features from the user. If the user believes the list is wrong or simply has a compiler currently not in the list he can request to do test-compiles for everything requested and use that results. In fact the testcase on all platforms will just do exactly that: request all features and compare it with the static list. So basically this is just a pre-populated cache. Afterwards CMake will go through several lists to find out if a compiler flag is needed to get that feature enabled. If those features are in the public interface of a library target they will be populated upwards. One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. Steve, anything important I missed? Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Am Mittwoch, 9. Oktober 2013, 15:54:18 schrieb Brad King: On 10/09/2013 12:21 PM, Rolf Eike Beer wrote: One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. After the Clang platform files load the GNU files to get the flags they will have to do their own logic to populate the feature lists. They can pass some indicator variable into the GNU files to block the GNU feature lists. The question is if that plugin situation is actually detectable. I understood the situation that you fixed to be a clang binary that just understands the other compilers arguments. In the situation I mean you have actually 2 compilers involved. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FLAGS on Darwin and custom languages
On Wed, Oct 9, 2013 at 2:18 PM, Brad King brad.k...@kitware.com wrote:
On 10/08/2013 07:12 PM, Vittorio Giovara wrote:
I noticed that in 2.8.11 under OSX CMake adds -F/Library/Frameworks in
every kind of FLAGS rule, for any language.
The flag is hard-coded in the C++-implemented generator code under
the assumption that all compilers on APPLE support -F. The -F
option appears in a few places literally in the C++ source:
$ git grep -- '-F' v2.8.11 -- 'Source/*.cxx'
v2.8.11:Source/cmCTest.cxx: if(this-CheckArgument(arg, -F))
v2.8.11:Source/cmLocalGenerator.cxx: -F
this-Convert(frameworkDir.c_str(),
v2.8.11:Source/cmLocalGenerator.cxx:frameworkPath += -F;
v2.8.11:Source/cmMakefileTargetGenerator.cxx:flags += -F;
v2.8.11:Source/cmQtAutomoc.cxx:this-MocIncludes.push_back(-F);
v2.8.11:Source/ctest.cxx: {-F, Enable failover., This option allows
ctest to resume a test
Take a look at the occurrences in cmLocalGenerator.cxx and in
cmMakefileTargetGenerator.cxx. The hard-coded -F should be
replaced with a platform information variable lookup that depends
on the language. One could introduce a new variable such as
CMAKE_LANG_FRAMEWORK_SEARCH_FLAG
and set it to -F in the upstream platform files but not in your
pascal file.
-Brad
Hi Brad thank you for your reply and insights.
I'm kinda puzzled though, by your explanation it appears that by
design a flag has been hardcoded in the compiler flags with no option
to disable it. Isn't the role of a build system such as cmake to avoid
making assumptions and allow users to customize its scripts? I also
fail to see the actual need of this addition since
-F/Library/Frameworks is the default framework directory on OSX, and
users needing to change it could just pass it along the other
parameters.
Anyway, I don't want to introduce a variable to change this behaviour,
in my opinion this flag should be either removed from FLAGS (or
introduce a policy to remove it) or as a quick hack this flag could be
moved at the beginning so that I could hijack the first element and
pass it to the linker. However either solution will work only for
future releases, what can be done to prevent this wrong behaviour on
the two CMake releases that feature it?
Vittorio
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Cmake configure unicode?
Should cmake be able to configure unicode, if the unicode file has
appropriate byte order indicators maybe?
I know it doesn't... for windows (and a bad test for if windows at that)
macro( DO_CONFIGURE_FILE input output )
if( $ENV{COMSPEC} MATCHES cmd )
STRING( REPLACE / \\ s1 ${CMAKE_CURRENT_SOURCE_DIR}/${input} )
STRING( REPLACE / \\ s2 ${CMAKE_BINARY_DIR}/${output} )
STRING( REPLACE / \\ finalout
${CMAKE_INSTALL_PREFIX}/${INTERFACE_OUTPUT_DIR}/${output} )
STRING( REPLACE / \\ leader
${CMAKE_CURRENT_SOURCE_DIR}\\BlankUnicode.txt )
EXECUTE_PROCESS(COMMAND cmd /c type ${s1} OUTPUT_FILE ${s2}.tmp )
configure_file( ${s2}.tmp ${s2}.configured )
EXECUTE_PROCESS(COMMAND cmd /U /C type ${s2}.configured
OUTPUT_FILE ${s2}.configured.unicode )
EXECUTE_PROCESS(COMMAND cmd /c copy /b
${leader}+${s2}.configured.unicode ${finalout} )
else()
message( NO METHOD TO CONFIGURE INTERFACE FILES )
abort()
endif( $ENV{COMSPEC} MATCHES cmd )
endmacro( DO_CONFIGURE_FILE )
Seems to work using a few temporary files and command prompt's copy
command to do the translation.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
