[cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler
Hi, I ran into a problem with SunPro Fortran compiler not being able to create a shared library since the -KPIC flag was missing. The patch that is attached fixes this. I didn't add a -KPIE as that doesn't exist for SunPro. Looking at other compiler configurations, it seems it might be better to have a SunPro.cmake module that combines flags that are independent of the language? greetings, Steven -- Steven Vancoillie Theoretical Chemistry Lund University P.O.B 124 S-221 00 Lund Sweden From f4efea633c55e384454e2f879144fa621510d6bb Mon Sep 17 00:00:00 2001 From: Steven Vancoillie steven.vancoil...@runbox.com Date: Fri, 20 Mar 2015 09:13:00 +0100 Subject: [PATCH] Add position independent code flag for SunPro Fortran compiler. --- Modules/Compiler/SunPro-Fortran.cmake | 1 + 1 file changed, 1 insertion(+) diff --git a/Modules/Compiler/SunPro-Fortran.cmake b/Modules/Compiler/SunPro-Fortran.cmake index e4db1e8..196aae4 100644 --- a/Modules/Compiler/SunPro-Fortran.cmake +++ b/Modules/Compiler/SunPro-Fortran.cmake @@ -2,6 +2,7 @@ set(CMAKE_Fortran_VERBOSE_FLAG -v) set(CMAKE_Fortran_FORMAT_FIXED_FLAG -fixed) set(CMAKE_Fortran_FORMAT_FREE_FLAG -free) +set(CMAKE_Fortran_COMPILE_OPTIONS_PIC -KPIC) set(CMAKE_SHARED_LIBRARY_Fortran_FLAGS -KPIC) set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS -G) set(CMAKE_SHARED_LIBRARY_RUNTIME_Fortran_FLAG -R) -- 2.3.3 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
* The option to use existing headers instead of autogenerated ones. My solution (which is about PCH support to existing CMake version) does not auto generate any headers. * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. My solution needs to generate additional target indeed for one pre-generated header, so if all your 1000+ targets will share same precompiled header (given the compiler flags don't change) then you will have just one (single) additional target. If CMake will support PCH natively I don't see any reason it will need extra target, yet obviously there will be extra (Ninja) compiler rule for PCH. -- Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
My solution needs to generate additional target indeed for one pre-generated header, so if all your 1000+ targets will share same precompiled header (given the compiler flags don't change) then you will have just one (single) additional target. It's very rare (not to mention risky) to be able to share a PCH with more than one target, because each target can have its own set of defines/flags and header inclusions, so we'd really end up with additional 1000+ targets. BTW, please note that the most recent test is still https://github.com/nanoant/CMakePCHCompiler/issues/1#issuecomment-77003296 If CMake will support PCH natively I don't see any reason it will need extra target, yet obviously there will be extra (Ninja) compiler rule for PCH. That's far better than extra targets. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support of codesign
Sorry, I'm also very late on this thread, but there was a suggestion that codesigning should be in CMake instead of CPack. I agree and also say it needs to be integrated as part of the build process when specified. Here's a real world workflow. I use JavaScriptCore in my Mac application which allows me to run various bits of JavaScript inside my main application, as you would with other embedded scripting languages like Lua. Safari has a feature that lets you attach the Safari built-in debugger to other applications JavaScriptCore contexts if you set the entitlement com.apple.security.get-task-allow. In order to set the entitlement, you must codesign. And I want to emphasize, this is a standard development workflow, not a release workflow which means this is the common case. The workflow should be: - Edit code in your app - Hit the Xcode run button to recompile and run/test. CMake's current workflow doesn't work this way and it is annoying. There are other things on Mac that require codesigning, such as if you use sandboxing (some APIs behave differently under sandboxing so testing under non-sandboxing has risks), or if you use certain Apple services like iCloud, In-App-Purchases, and Game Center. An additional note, any 3rd party libraries/frameworks embedded in the app also must be codesigned. I currently employed my own workarounds for both using a lot of post_build/custom_command instructions. However my solution is still a little clumsy with switching between different codesign keys (Developer ID vs Mac App Store vs none). It would be nicer if you could pick it in Xcode directly instead of having to regenerate CMake everytime. Additionally, resigning all the 3rd party frameworks every single time is kind of slow (my algorithm is kind of stupid), but there are additional complications when you change the key to sign with which is partly why my algorithm ended up playing stupid. Thanks, Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/19/2015 09:57 AM, Geoffrey Viola wrote: Fixed. Great, thanks. I'll take another look at the updated patch next week. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: Helper macros for writing Find modules
On 03/18/2015 05:50 PM, Alex Merry wrote: I made some changes in a copy of this module for work that separated out the target creation, as well as adding debug/release support. I'll check about being allowed to release that work, but I doubt it'll be an issue. Great. Will you be able to test this by factoring it into ECM proper? One attractive feature of this particular work is that ECM is well tested and widely used, so the modules can come with some maturity. Help: Drop FeatureSummary example in cmake-developer.7 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe One issue I realised with this after the fact is that it works poorly with *Config.cmake files - if there is no find module, and the package is not found, the URL telling you how to get hold of it would be missing unless you add it at the find_package call site. That's a good point. When FeatureSummary was first introduced I always envisioned it being used in project code near the find_package call sites but not underneath them in the call stack. The goal of the *Config file approach to find_package is to have no information about the package hard-coded in CMake, because doing so is not scalable to every package in the world. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
Two requests please: * The option to use existing headers instead of autogenerated ones. * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. Regards, Amine. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler
On 03/20/2015 04:23 AM, Steven Vancoillie wrote: I ran into a problem with SunPro Fortran compiler not being able to create a shared library since the -KPIC flag was missing. The patch that is attached fixes this. I didn't add a -KPIE as that doesn't exist for SunPro. Applied, thanks: SunPro: Add position independent code flag for Fortran compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3556fb1b Looking at other compiler configurations, it seems it might be better to have a SunPro.cmake module that combines flags that are independent of the language? Yes. This refactoring has simply not been done for this compiler. If you want to work on it, please note that such a module is not loaded automatically and must be included by the per-language modules. This pattern is visible in several other compiler modules. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
On 03/13/2015 08:44 AM, Daniel Pfeifer wrote: I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch Thanks for working on this. I'm hoping others will respond because I have little experience with PCH. target_precompile_headers(bar INTERFACE bar.h) [snip] This command is used to set a list of headers to precompile. This would say that any target that links to 'bar' would get 'bar.h' as a source file to be precompiled for that target's settings. This makes some sense for producing the precompiled header, but what decides what precompiled header is *used* by each source file? IIUC a given compiler call may specify at most one precompiled header to use because it is actually more like a partially compiled translation unit to be continued by each source consuming it. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi amine.kha...@reactos.org wrote: Two requests please: * The option to use existing headers instead of autogenerated ones. That is an implementation detail. It should not make a difference whether the precompiled header is used through your existing header or through an autogenerated header that forward includes your existing header. This forward inclusion is important at least for GCC: The compiler searches for a .gch file in the same directory as the header file. Since we do not want this .gch file to be generated in the source directory for out-of-source builds, we need to put the header file into the build directory. Did I misunderstand your request and you meant use an existing *precompiled* header, ie. provide a .pch or .gch file? My approach currently does not support that. Please let me know if that is what you meant. * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. I completely agree. One request that I can add: * It shall be visible in the IDE's settings that precompiled headers are used. Cheers, Daniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015461]: Ninja generator does not honor COMMENT for TARGET POST_BUILD commands
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15461
==
Reported By:Chris Green
Assigned To:
==
Project:CMake
Issue ID: 15461
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-03-20 15:37 EDT
Last Modified: 2015-03-20 15:37 EDT
==
Summary:Ninja generator does not honor COMMENT for TARGET
POST_BUILD commands
Description:
Upon adding a TARGET POST_BUILD command to make an alias link for a built
library, the Ninja system does not print my defined COMMENT.
Steps to Reproduce:
Define a custom command as a POST_BUILD command to (e.g.) a library target, and
define a COMMENT.
Run CMake -GNinja.
Run ninja log.txt 21
Fail to see your COMMENT in log.txt.
Additional Information:
The COMMENT is printed as expected with the UNIX Makefile generator in CMake
3.2.1.
The actual command we used:
function(cet_lib_alias LIB_TARGET)
foreach(alias ${ARGN})
add_custom_command(TARGET ${LIB_TARGET}
POST_BUILD
COMMAND ln -sf $TARGET_LINKER_FILE_NAME:${LIB_TARGET}
${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX}
COMMENT Generate / refresh courtesy link
${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} -
$TARGET_LINKER_FILE_NAME:${LIB_TARGET}
VERBATIM
WORKING_DIRECTORY ${LIBRARY_OUTPUT_PATH})
endforeach()
endfunction()
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-20 15:37 Chris GreenNew Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
