Re: [cmake-developers] CPack IFW generator
Thank you Brad ! Apologies for the delay in response, but these two weeks I fished and not programmed . As I said, I'm new to developing CMake. Thank you for making the patch , but I do not know what to do with it . Your comments are very valuable for me. I will try to use them in the future development of the generator. I understand that my project is not yet ready for release. I will make changes in my local repository (git :/ / podsvirov.pro / cmake / cpackifwgenerator.git ) When the code is stable , I want to make it available to the entire community. As always , I apologize for my bad English . 12.05.2014, 18:32, Brad King brad.k...@kitware.com: On 05/08/2014 03:14 AM, Konstantin Podsvirov wrote: Qt is distributed with of his Qt Installer Framework (QtIFW). For reference, here is a link: http://qt-project.org/wiki/Qt-Installer-Framework I decided to make friends CMake and QtIFW. I added CPack IFW generator and module FindIFW.cmake. Thanks for working on this. You can copy the code and test it: git clone git://podsvirov.pro/cmake/cpackifwgenerator.git For reference, I constructed a patch with the net change from your topic. I revised some whitespace too. See attachment. I'd appreciate comments from others on this mailing list that have worked on developing CPack generators. Also, I'm not familiar with IFW so I can only comment on this from the CMake/CPack side. The patch adds a FindIFW module and has CPack use it to find the packaging tools and add macro cpack_configure_ifw_component. In general find modules may not run reliably outside of a find_package() call in project CMake code (e.g. CMakeLists.txt) because no information about the host or target platform is available otherwise. Normally CPack generators have their own logic for finding the packaging tools. The location should not be needed outside of CPack. A separate module like CPackIFW could be used to provide the macro. We should not need a FindIFW module at all. -Brad Regards -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014935]: file(APPEND message...) writes nulls into file
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14935
==
Reported By:th.thielemann
Assigned To:
==
Project:CMake
Issue ID: 14935
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-05-26 04:56 EDT
Last Modified: 2014-05-26 04:56 EDT
==
Summary:file(APPEND message...) writes nulls into file
Description:
I am using a shared folder between my Win7 and VmWare with Ubuntu 12.04.
Fore some reasons I write out some properties into a file during cmake run.
First line with file(WRITE key=value). All others with file(APPEND ...)
Sucessful tested on Windows, Linux using the local file system. But if I share a
folder between Windows and Linux, the result is 00 00 00 00 ... 00 The appended
message.
Steps to Reproduce:
Create the environment Win7 + VmWare + Ubuntu 12.04 LTS + shared folder.
Here is my function
function(write_env_script Mode EnvKey EnvValue)
# Possible option flags
list(FIND ARGN EXTEND IsExtend)
# Resulting script name
if(CMAKE_HOST_WIN32)
file(TO_NATIVE_PATH ${EnvValue} EnvValue)
endif()
set(ScriptName ${PROJECT_BINARY_DIR}/setprojectenv${SSP_SCRIPT_TYPE})
# Reset mode to WRITE if file does not exist
if((${Mode} STREQUAL APPEND) AND (NOT EXISTS ${ScriptName}))
set(Mode WRITE)
endif()
# overwrite or extend the env variable's value
set(EnvValueAlreadySet -1)
if(NOT IsExtend EQUAL -1)
if(NOT $ENV{${EnvKey}} STREQUAL )
if(CMAKE_HOST_UNIX)
set(CurrentEnvValue $ENV{${EnvKey}}:)
elseif(CMAKE_HOST_WIN32)
set(CurrentEnvValue $ENV{${EnvKey}};)
endif()
endif()
# Contains the env variable the value already?
string(FIND $ENV{${EnvKey}} ${EnvValue} EnvValueAlreadySet REVERSE)
endif()
if(EnvValueAlreadySet EQUAL -1)
if(CMAKE_HOST_UNIX)
Error! Replace the following line with workaround
file(${Mode} ${ScriptName}
${PreviousScriptContent} export
${EnvKey}=${CurrentEnvValue}${EnvValue}\n )
execute_process(COMMAND chmod u+x ${ScriptName}
WORKING_DIRECTORY
${PROJECT_BINARY_DIR})
elseif(CMAKE_HOST_WIN32)
file(${Mode} ${ScriptName} set
${EnvKey}=${CurrentEnvValue}${EnvValue}\n\r )
endif()
endif()
endfunction()
The workaround for linux using VmWare share.
if(${Mode} STREQUAL APPEND)
file(READ ${ScriptName} PreviousScriptContent)
endif()
file(WRITE ${ScriptName} ${PreviousScriptContent}
export
${EnvKey}=${CurrentEnvValue}${EnvValue}\n )
Usage of the function:
write_env_script(APPEND QT_PLUGIN_PATH ${QtLibs_PATH}/plugins)
write_env_script(APPEND QML2_IMPORT_PATH ${QtLibs_PATH}/qml)
write_env_script(APPEND PATH ${QtLibs_PATH}/bin EXTEND)
==
Issue History
Date ModifiedUsername FieldChange
==
2014-05-26 04:56 th.thielemann New 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014936]: CMAKE_GNUtoMS_VCVARS is not set when using Visual Studio 12 2013 and CMakeAddFortranSubdirectory
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14936 == Reported By:neologius Assigned To: == Project:CMake Issue ID: 14936 Category: CMake Reproducibility:always Severity: minor Priority: high Status: new == Date Submitted: 2014-05-26 06:14 EDT Last Modified: 2014-05-26 06:14 EDT == Summary:CMAKE_GNUtoMS_VCVARS is not set when using Visual Studio 12 2013 and CMakeAddFortranSubdirectory Description: In Windows-GNU.cmake, find_program is used to discover the batch file that sets up the Visual C++ command line environment by inspecting certain registry entries. There is no inspection of the registry key where visual studio 2013 stores its installation directory. Moreover, in Visual Studio 2013, the name of the batch file has been changed slightly requiring appending a name to search for in the find_program NAMES list. Both issues can be fixed by slightly modifying the cmake file (see attachment). Steps to Reproduce: Use CMakeAddFortranSubdirectory with Visual Studio 12 Win64 and gfortran. == Issue History Date ModifiedUsername FieldChange == 2014-05-26 06:14 neologius New Issue 2014-05-26 06:14 neologius File Added: Windows-GNU.cmake == -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
Hi everybody there,
Subject says it all. See the attached patch please.
(Didn't care enough to leave hg for git to generate the patch. Sorry.)
# HG changeset patch
# User Ebrahim Mohammadi mebra...@gmail.com
# Date 1401098735 -16200
# Mon May 26 14:35:35 2014 +0430
# Node ID 0b2fc1eb05f57c9147b5cfb77b7e1887b443f3b2
# Parent a9bf99d5c158d15d204838ab7dca6fb588ad0018
Fix error in compiling C++ files generating by protobuf compiler when .proto
files are organized in a directory hierarchy.
diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -173,7 +173,9 @@
set(${HDRS})
foreach(FIL ${ARGN})
get_filename_component(ABS_FIL ${FIL} ABSOLUTE)
-get_filename_component(FIL_WE ${FIL} NAME_WE)
+get_filename_component(FILE_NAME_WE ${FIL} NAME_WE)
+get_filename_component(FILE_PATH ${FIL} PATH)
+set(FIL_WE ${FILE_PATH}/${FILE_NAME_WE})
list(APPEND ${SRCS} ${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.cc)
list(APPEND ${HDRS} ${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.h)
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
Hi everybody there, Subject says it all. See the attached patch please. (Didn't care enough to leave hg for git to generate the patch. Sorry.) FILE_PATH is likely to contain C: or some other drive letter on Windows. It is therefore unsuitable for using to construct a sub-path underneath CMAKE_CURRENT_BINARY_DIR. You don't have to care enough to leave hg, but we do have to care enough to make sure CMake still works on all the platforms it's intended to work on. This patch may fix your particular use case, but it is not generally correct, and therefore, unlikely to be adopted into upstream CMake. There must be a better solution, that will work on all platforms... David C. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
${FILE_PATH} is PATH part of ${FIL} and ${FIL} is path of each of .proto
files relative to CMakeLists.txt as the user has entered in CMakeLists.txt.
So ${FIL} and consequently ${FILE_PATH} cannot contain drive letters in a
genuine usage scenario. Or I'm missing something.
On Mon, May 26, 2014 at 3:45 PM, David Cole dlrd...@aol.com wrote:
Hi everybody there,
Subject says it all. See the attached patch please.
(Didn't care enough to leave hg for git to generate the patch. Sorry.)
FILE_PATH is likely to contain C: or some other drive letter on
Windows. It is therefore unsuitable for using to construct a sub-path
underneath CMAKE_CURRENT_BINARY_DIR.
You don't have to care enough to leave hg, but we do have to care
enough to make sure CMake still works on all the platforms it's
intended to work on.
This patch may fix your particular use case, but it is not generally
correct, and therefore, unlikely to be adopted into upstream CMake.
There must be a better solution, that will work on all platforms...
David C.
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
Maybe I'm missing something. Is it guaranteed that all callers of PROTOBUF_GENERATE_CPP will pass non-full-path names for the .proto source files? If so, then I retract my statement. But I don't think you can guarantee that. David C. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
I think the user is supposed not to pass full paths to
PROTOBUF_GENERATE_CPP. Because if user does so, there is a more severe bug
right now in the code: if user provides both /some/path/A.proto and
/another/path/A.proto to PROTOBUF_GENERATE_CPP, C++ file of both A.proto
files will be generated in ${CMAKE_CURRENT_BINARY_DIR}/A.cpp. In other
words C++ file of one A.proto overwrites C++ of the other A.proto file.
So I think the original author of FindProtobuf.cmake has intended the user
to provide relative paths to .proto files, and he/she has been mostly
considering cases where .proto files are placed right in the same directory
as CMakeLists.txt, rather than more complex cases like .proto files
organized in a directory hierarchy which I'm recently hit a bug about. On
the other hand I can't think of a genuine use case where user needs to use
PROTOBUF_GENERATE_CPP on absolute paths.
Long story short I think it is safe to assume PROTOBUF_GENERATE_CPP is
intended to be used on relative paths. But again maybe I'm missing
something! So correct me if I'm wrong. :)
On Mon, May 26, 2014 at 11:58 PM, David Cole dlrd...@aol.com wrote:
Maybe I'm missing something. Is it guaranteed that all callers of
PROTOBUF_GENERATE_CPP will pass non-full-path names for the .proto source
files?
If so, then I retract my statement. But I don't think you can guarantee
that.
David C.
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy
... Long story short I think it is safe to assume ... It is never safe to assume anything. I don't have personal experience with protobuf But in general, inputs to CMake are allowed to be full path or not, and when not, they're usually treated relative to CMAKE_CURRENT_SOURCE_DIR. Consult the documentation on individual functions for details. After this, I'll be quiet on this, but I wouldn't accept the patch as is without a guarantee that relative paths are the only ones allowed as input. Hopefully, Philip Lowman is listening, and he can chime in. He's listed as the FindProtobuf module maintainer here: http://www.cmake.org/Wiki/CMake:Module_Maintainers Cheers, David C. -- 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/cgi-bin/mailman/listinfo/cmake-developers
