[Cmake-commits] CMake branch, master, updated. v3.13.3-957-g92d1321

2019-01-17 Thread Kitware Robot via Cmake-commits
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  92d132100a0097c867eaa73f4bcca59670cca4f3 (commit)
  from  68e20f674a48be38d60e129f600faf7c483f2b97 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92d132100a0097c867eaa73f4bcca59670cca4f3
commit 92d132100a0097c867eaa73f4bcca59670cca4f3
Author: Kitware Robot 
AuthorDate: Fri Jan 18 00:01:05 2019 -0500
Commit: Kitware Robot 
CommitDate: Fri Jan 18 00:01:05 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index dd9eccd..245bd71 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20190117)
+set(CMake_VERSION_PATCH 20190118)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits


Re: [CMake] CPack and WIX: Preselected components

2019-01-17 Thread Kyle Edwards via CMake
Micha,

Unfortunately, the WiX generator does not currently support component
installation, which is what's needed to make the INSTALL_TYPES argument
work.

We would welcome a merge request which adds this support.

Kyle

On Thu, 2019-01-17 at 19:28 +0100, Micha Renner wrote:
> With the NSIS generator I can create a dialog with a drop_down list
> with two elements default and developer. Default is selected by
> default
> when the dialog starts, so the default parts of the package are
> installed. Selecting developer the devlop parts are installed and the
> default files not. 
> 
> How can I do the same with the WiX generator?
> 
> With code below the WiX generator installs the complete package. 
> What I want is that the user can selected the develop part if he
> wants
> it.
> 
> 
> ___
> Example as it works with NSIS. There is nothing specific for NSIS.
> 
> ADD_LIBRARY(mylib mylib.c)
> 
> ADD_EXECUTABLE(myapp myapp.c mylib.h)
> TARGET_LINK_LIBRARIES(myapp mylib)
> 
> INSTALL(TARGETS mylib ARCHIVE DESTINATION lib COMPONENT libraries)
> INSTALL(TARGETS myapp RUNTIME DESTINATION bin COMPONENT applications)
> INSTALL(FILES mylib.h DESTINATION include COMPONENT headers)
> INSTALL(FILES free.txt DESTINATION doc COMPONENT dokumentation)
> 
> # WIX specific
> SET(CPACK_WIX_UPGRADE_GUID 939B61C9-8E66-4876-A425-F7CDD7E6A6B2)
> SET(CPACK_GENERATOR WIX)
> 
> INCLUDE(CPackComponent)
> 
> cpack_add_install_type(Default DISPLAY_NAME Default)
> cpack_add_install_type(Developer)
> 
> cpack_add_component(applications DISPLAY_NAME "App" DESCRIPTION
> "Application only"
> GROUP "Runtime" INSTALL_TYPES Default)
> 
> cpack_add_component(dokumentation DISPLAY_NAME "Doc" DESCRIPTION "Doc
> for the app"
> GROUP "Runtime" INSTALL_TYPES Default)
>   
> cpack_add_component(libraries DISPLAY_NAME "lib" DESCRIPTION "For
> devloper only"
>   GROUP "Development" INSTALL_TYPES Developer)
> 
> cpack_add_component(headers DISPLAY_NAME "C++ Headers" DESCRIPTION
> "C/C++ header files for use with MyLib"
> DEPENDS libraries INSTALL_TYPES Developer GROUP "Development")
> 
> cpack_add_component_group(Runtime)
> cpack_add_component_group(Development DESCRIPTION "All you need for
> development")
> 
> SET(CPACK_COMPONENT_GROUP_DEVELOPMENT_PARENT_GROUP "Runtime")
> 
> INCLUDE(CPack)
> 
-- 

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] CPack and WIX: Preselected components

2019-01-17 Thread Micha Renner
With the NSIS generator I can create a dialog with a drop_down list
with two elements default and developer. Default is selected by default
when the dialog starts, so the default parts of the package are
installed. Selecting developer the devlop parts are installed and the
default files not. 

How can I do the same with the WiX generator?

With code below the WiX generator installs the complete package. 
What I want is that the user can selected the develop part if he wants
it.


___
Example as it works with NSIS. There is nothing specific for NSIS.

ADD_LIBRARY(mylib mylib.c)

ADD_EXECUTABLE(myapp myapp.c mylib.h)
TARGET_LINK_LIBRARIES(myapp mylib)

INSTALL(TARGETS mylib ARCHIVE DESTINATION lib COMPONENT libraries)
INSTALL(TARGETS myapp RUNTIME DESTINATION bin COMPONENT applications)
INSTALL(FILES mylib.h DESTINATION include COMPONENT headers)
INSTALL(FILES free.txt DESTINATION doc COMPONENT dokumentation)

# WIX specific
SET(CPACK_WIX_UPGRADE_GUID 939B61C9-8E66-4876-A425-F7CDD7E6A6B2)
SET(CPACK_GENERATOR WIX)

INCLUDE(CPackComponent)

cpack_add_install_type(Default DISPLAY_NAME Default)
cpack_add_install_type(Developer)

cpack_add_component(applications DISPLAY_NAME "App" DESCRIPTION
"Application only"
GROUP "Runtime" INSTALL_TYPES Default)

cpack_add_component(dokumentation DISPLAY_NAME "Doc" DESCRIPTION "Doc
for the app"
GROUP "Runtime" INSTALL_TYPES Default)

cpack_add_component(libraries DISPLAY_NAME "lib" DESCRIPTION "For
devloper only"
GROUP "Development" INSTALL_TYPES Developer)

cpack_add_component(headers DISPLAY_NAME "C++ Headers" DESCRIPTION
"C/C++ header files for use with MyLib"
DEPENDS libraries INSTALL_TYPES Developer GROUP "Development")

cpack_add_component_group(Runtime)
cpack_add_component_group(Development DESCRIPTION "All you need for
development")

SET(CPACK_COMPONENT_GROUP_DEVELOPMENT_PARENT_GROUP "Runtime")

INCLUDE(CPack)

-- 

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] Qt translation handling

2019-01-17 Thread Francis Giraldeau
Here is a small snipped I wanted to share about generation of qt translation

files.


The Qt translations are managed using two files: ts and qm. The ts files are
edited by translators and updated from source files. Therefore, they must be
added to the repository. To include the translations in the application, qm
binary file is generated. This file is generated in the build tree and must
not be added to the repository.

Qt5 suggests to use qt5_create_translation() macro. However, this macro
regenerate the ts file at build time. It is very inconvenient when working
on multiple branches, because it forces to either commit the modified
translation file or discard the update. Instead, we use a custom target
"make translations" that update ts files only when requested explicitely.

set(TS_FILES
${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts
)
file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui")
add_custom_target(translations)
foreach(_ts_file ${TS_FILES})

# generate a sensible name for this translation file
get_filename_component(_ts_name ${_ts_file} NAME_WE)

# call lupdate ourselves
add_custom_command(
OUTPUT "${_ts_file}"
DEPENDS ${TS_SOURCES}
COMMAND ${Qt5_LUPDATE_EXECUTABLE} -recursive
${CMAKE_CURRENT_SOURCE_DIR} -ts ${_ts_file}
)

# create a target that depends on the generated files
add_custom_target(translate_${_ts_name} DEPENDS ${_ts_file})

# attach the custom target for this ts file to the parent target
add_dependencies(translations translate_${_ts_name})
endforeach()

# generate qm files
qt5_add_translation(QM_FILES ${TS_FILES})
configure_file(translations.qrc ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)


add_executable(App

${QM_FILES}

${CMAKE_CURRENT_BINARY_DIR}/translations.qrc

)


Cheers,


Francis

-- 
Francis Giraldeau
-- 

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:
https://cmake.org/mailman/listinfo/cmake


[Cmake-commits] CMake branch, master, updated. v3.13.3-956-g68e20f6

2019-01-17 Thread Kitware Robot via Cmake-commits
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  68e20f674a48be38d60e129f600faf7c483f2b97 (commit)
   via  4568d046c46a7357ab48ddfb1117bad39e65572c (commit)
  from  bd3685b6cfac90bb553df0330e1732c066fe7dca (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68e20f674a48be38d60e129f600faf7c483f2b97
commit 68e20f674a48be38d60e129f600faf7c483f2b97
Merge: bd3685b 4568d04
Author: Brad King 
AuthorDate: Thu Jan 17 16:43:02 2019 +
Commit: Kitware Robot 
CommitDate: Thu Jan 17 11:43:09 2019 -0500

Merge topic 'cmake_role-global-property'

4568d046c4 Properties: Add CMAKE_ROLE global property

Acked-by: Kitware Robot 
Merge-request: !2805


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4568d046c46a7357ab48ddfb1117bad39e65572c
commit 4568d046c46a7357ab48ddfb1117bad39e65572c
Author: Kyle Edwards 
AuthorDate: Mon Jan 14 12:27:14 2019 -0500
Commit: Kyle Edwards 
CommitDate: Thu Jan 17 09:44:29 2019 -0500

Properties: Add CMAKE_ROLE global property

This property allows scripts to determine whether they're in project
mode, script mode, find-package mode, CTest, or CPack.

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index df8f12c..02aaf4a 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -23,6 +23,7 @@ Properties of Global Scope
/prop_gbl/AUTORCC_SOURCE_GROUP
/prop_gbl/CMAKE_C_KNOWN_FEATURES
/prop_gbl/CMAKE_CXX_KNOWN_FEATURES
+   /prop_gbl/CMAKE_ROLE
/prop_gbl/DEBUG_CONFIGURATIONS
/prop_gbl/DISABLED_FEATURES
/prop_gbl/ENABLED_FEATURES
diff --git a/Help/prop_gbl/CMAKE_ROLE.rst b/Help/prop_gbl/CMAKE_ROLE.rst
new file mode 100644
index 000..27512fa
--- /dev/null
+++ b/Help/prop_gbl/CMAKE_ROLE.rst
@@ -0,0 +1,20 @@
+CMAKE_ROLE
+--
+
+Tells what mode the current running script is in. Could be one of several
+values:
+
+``PROJECT``
+  Running in project mode (processing a ``CMakeLists.txt`` file).
+
+``SCRIPT``
+  Running in ``-P`` script mode.
+
+``FIND_PACKAGE``
+  Running in ``--find-package`` mode.
+
+``CTEST``
+  Running in CTest script mode.
+
+``CPACK``
+  Running in CPack.
diff --git a/Help/release/dev/cmake_role-global-property.rst 
b/Help/release/dev/cmake_role-global-property.rst
new file mode 100644
index 000..7b1fa0b
--- /dev/null
+++ b/Help/release/dev/cmake_role-global-property.rst
@@ -0,0 +1,6 @@
+cmake_role-global-property
+--
+
+* A new global property, :prop_gbl:`CMAKE_ROLE`, was added to allow scripts to
+  determine whether they're running in project mode, script mode, find-package
+  mode, CTest, or CPack.
diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx
index acd6650..b205105 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -18,6 +18,7 @@
 #include "cmGeneratedFileStream.h"
 #include "cmGlobalGenerator.h"
 #include "cmMakefile.h"
+#include "cmState.h"
 #include "cmStateSnapshot.h"
 #include "cmVersion.h"
 #include "cmWorkingDirectory.h"
@@ -690,7 +691,7 @@ int cmCPackGenerator::InstallCMakeProject(
   "-   Install component: " << component << std::endl);
   }
 
-  cmake cm(cmake::RoleScript);
+  cmake cm(cmake::RoleScript, cmState::CPack);
   cm.SetHomeDirectory("");
   cm.SetHomeOutputDirectory("");
   cm.GetCurrentSnapshot().SetDefaultDefinitions();
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index 4e49727..db9a0e7 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -24,6 +24,7 @@
 #include "cmDocumentationFormatter.h"
 #include "cmGlobalGenerator.h"
 #include "cmMakefile.h"
+#include "cmState.h"
 #include "cmStateSnapshot.h"
 #include "cmSystemTools.h"
 #include "cmake.h"
@@ -208,7 +209,7 @@ int main(int argc, char const* const* argv)
   cmCPack_Log(, cmCPackLog::LOG_VERBOSE,
   "Read CPack config file: " << cpackConfigFile << std::endl);
 
-  cmake cminst(cmake::RoleScript);
+  cmake cminst(cmake::RoleScript, cmState::CPack);
   cminst.SetHomeDirectory("");
   cminst.SetHomeOutputDirectory("");
   cminst.SetProgressCallback(cpackProgressCallback, nullptr);
diff --git a/Source/CTest/cmCTestBuildAndTestHandler.cxx 
b/Source/CTest/cmCTestBuildAndTestHandler.cxx
index 668a387..d49fba2 100644
--- a/Source/CTest/cmCTestBuildAndTestHandler.cxx
+++ b/Source/CTest/cmCTestBuildAndTestHandler.cxx
@@ -6,6 +6,7 @@
 #include "cmCTestTestHandler.h"
 #include "cmGlobalGenerator.h"
 #include "cmMakefile.h"
+#include "cmState.h"
 #include "cmSystemTools.h"
 #include 

[Cmake-commits] CMake branch, master, updated. v3.13.3-954-gbd3685b

2019-01-17 Thread Kitware Robot via Cmake-commits
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  bd3685b6cfac90bb553df0330e1732c066fe7dca (commit)
   via  9e3e93fc6f642e2cf0c1f11753ff8e2267d49ded (commit)
   via  22b43b0009f37c41b310dd26a4ecb00361975aaa (commit)
   via  a541d113e606b05073810bb1b5dd5a7a8fd2eec8 (commit)
  from  c144db1b8ca1ea2e3dad397123f110956a439030 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd3685b6cfac90bb553df0330e1732c066fe7dca
commit bd3685b6cfac90bb553df0330e1732c066fe7dca
Merge: 9e3e93f 22b43b0
Author: Brad King 
AuthorDate: Thu Jan 17 16:07:05 2019 +
Commit: Kitware Robot 
CommitDate: Thu Jan 17 11:07:11 2019 -0500

Merge topic 'vs-debug-utility-targets'

22b43b0009 VS: Add support for VS_DEBUGGER_* properties on custom targets

Acked-by: Kitware Robot 
Merge-request: !2794


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e3e93fc6f642e2cf0c1f11753ff8e2267d49ded
commit 9e3e93fc6f642e2cf0c1f11753ff8e2267d49ded
Merge: c144db1 a541d11
Author: Brad King 
AuthorDate: Thu Jan 17 16:05:57 2019 +
Commit: Kitware Robot 
CommitDate: Thu Jan 17 11:06:04 2019 -0500

Merge topic 'fix_csharp_defines'

a541d113e6 VS: Honor target_compile_definitions for C# projects

Acked-by: Kitware Robot 
Merge-request: !2809


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22b43b0009f37c41b310dd26a4ecb00361975aaa
commit 22b43b0009f37c41b310dd26a4ecb00361975aaa
Author: Nils Gladitz 
AuthorDate: Fri Jan 11 21:29:58 2019 +0100
Commit: Brad King 
CommitDate: Wed Jan 16 10:21:01 2019 -0500

VS: Add support for VS_DEBUGGER_* properties on custom targets

Visual studio itself supports the corresponding `LocalDebugger*`
properties on utility targets; support generating them from CMake as
well.

diff --git a/Help/release/dev/vs-debug-utility-targets.rst 
b/Help/release/dev/vs-debug-utility-targets.rst
new file mode 100644
index 000..02e5262
--- /dev/null
+++ b/Help/release/dev/vs-debug-utility-targets.rst
@@ -0,0 +1,6 @@
+vs-debug-utility-targets
+
+
+* :ref:`Visual Studio Generators` for VS 2010 and above learned
+  to support the ``VS_DEBUGGER_*`` properties on targets created
+  via :command:`add_custom_target`.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index dd90269..c685918 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -2283,6 +2283,58 @@ void 
cmVisualStudio10TargetGenerator::WritePathAndIncrementalLinkOptions(
   e1.Element("_ProjectFileVersion", "10.0.20506.1");
   for (std::string const& config : this->Configurations) {
 const std::string cond = this->CalcCondition(config);
+
+if (ttype <= cmStateEnums::UTILITY) {
+  if (const char* workingDir = this->GeneratorTarget->GetProperty(
+"VS_DEBUGGER_WORKING_DIRECTORY")) {
+cmGeneratorExpression ge;
+std::unique_ptr cge =
+  ge.Parse(workingDir);
+std::string genWorkingDir =
+  cge->Evaluate(this->LocalGenerator, config);
+
+e1.WritePlatformConfigTag("LocalDebuggerWorkingDirectory", cond,
+  genWorkingDir);
+  }
+
+  if (const char* environment =
+this->GeneratorTarget->GetProperty("VS_DEBUGGER_ENVIRONMENT")) {
+cmGeneratorExpression ge;
+std::unique_ptr cge =
+  ge.Parse(environment);
+std::string genEnvironment =
+  cge->Evaluate(this->LocalGenerator, config);
+
+e1.WritePlatformConfigTag("LocalDebuggerEnvironment", cond,
+  genEnvironment);
+  }
+
+  if (const char* debuggerCommand =
+this->GeneratorTarget->GetProperty("VS_DEBUGGER_COMMAND")) {
+
+cmGeneratorExpression ge;
+std::unique_ptr cge =
+  ge.Parse(debuggerCommand);
+std::string genDebuggerCommand =
+  cge->Evaluate(this->LocalGenerator, config);
+
+e1.WritePlatformConfigTag("LocalDebuggerCommand", cond,
+  genDebuggerCommand);
+  }
+
+  if (const char* commandArguments = this->GeneratorTarget->GetProperty(
+"VS_DEBUGGER_COMMAND_ARGUMENTS")) {
+cmGeneratorExpression ge;
+std::unique_ptr cge =
+  ge.Parse(commandArguments);
+std::string genCommandArguments =
+  cge->Evaluate(this->LocalGenerator, config);
+
+e1.WritePlatformConfigTag("LocalDebuggerCommandArguments", cond,
+  

Re: [CMake] [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual Studio 2017 Project

2019-01-17 Thread Robert Maynard via CMake
If the problem only occurs when using the command line shell it might be
related to other environment variables in the shell.

On Tue, Jan 15, 2019 at 5:20 AM Kail, Rajmund (GE Healthcare) <
rajmund.k...@ge.com> wrote:

> Dear All,
>
>
>
> I have another observation. The project is generated normally via
> cmake_gui.exe. The issue occurs only in cmd.
>
>
>
> Thank you in advance for your kind help,
>
>
>
> Best regards,
>
>
>
> Rajmund Kail
>
>
>
> *From:* Kail, Rajmund (GE Healthcare)
> *Sent:* Tuesday, January 15, 2019 11:10 AM
> *To:* cmake@cmake.org
> *Subject:* [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual
> Studio 2017 Project
>
>
>
> Dear All,
>
>
>
> I’m contacting you, because we are having issues with CMake a few days ago
> and it makes our daily work very difficult.
>
>
>
> The problem is that CMake cannot configure and generate a Visual Studio
> solution from an existing C++ codebase. We are attempting to generate a
> Visual Studio 2017 64-bit solution.
>
>
>
> As per the error message VCTargetsPath is not found, so MSBuild is
> crashing after a few seconds.
>
>
>
>
>
> I tried running MSBuild.exe in developer console, but it displays nothing
> at all. (The error code is 0x05).
>
>
>
>
>
> MSBuild.exe is executing in Powershell however.
>
>
>
>
>
> My question is how could we overcome the above issue? Could you please
> give us some possible workarounds or what direction should we take in order
> to investigate?
>
>
>
> Thank you in advance for your kind assistance,
>
>
>
> Best regards,
>
>
>
> Rajmund Kail
>
> C++ Software Engineer
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] FindPkgConfig and using -m32 on Linux

2019-01-17 Thread Jan Wielemaker
I'll answer myself. As the answer is a little contra intuitive, I'll
post it :)

After copying FindPkgConfig.cmake locally and adding a lot of message()
to it, I discovered a couple of things:

  - As FindPkgConfig claims, CMAKE_PREFIX_PATH, etc are added to the
search if CMAKE_MINIMUM_REQUIRED_VERSION >= 3.1.  Now this was
claimed 2.8.12 in my code, but in reality is 3.5.  I changed that
in the specific subdir to no avail.  Also changed it in the main,
to my suprise again, to no avail.  Only after cheanging it to 3.5
in all subdirs this started working.

So, it appears the effective CMAKE_MINIMUM_REQUIRED_VERSION is
the lowest of all demanded versions in the entire project.  That
seems a bit odd to me.  I had expected to be per directory or
be the _highest_.

  - FindPkgConfig _does_ add CMAKE_LIBRARY_ARCHITECTURE, but only
to the _extra_ directories.  As CMAKE_PREFIX_PATH is empty
(no special search places except for the CMAKE_LIBRARY_ARCHITECTURE
to find the i386 libs), nothing is added.  So, this works:

set(CMAKE_PREFIX_PATH /usr)
set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu)

The first set seems very odd :(  Possibly a more direct way to
add directories to the start/end of the PKG_CONFIG_PATH is more
intuitive?


Cheers --- Jan


On 17/01/2019 13:57, Jan Wielemaker wrote:
> Hi,
>
> I'm trying to build a complicated package for 32-bits on 64-bit Ubuntu.
> I got very far using
>
> set(CMAKE_C_FLAGS -m32)
> set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu)
>
> But right now, find_package(OpenSSL) is failing.  I think the problem is
> with FindOpenSSL.cmake doing this (Ubuntu 18.04, CMake 3.10):
>
> if (UNIX)
>   find_package(PkgConfig QUIET)
>   pkg_check_modules(_OPENSSL QUIET openssl)
> endif ()
>
> Ubuntu has, I think compatibe with the Linux standard, these .pc files
> for the multilib installed OpenSSL:
>
> $ dpkg -L libssl1.0-dev | grep openssl.pc
> /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc
> $ dpkg -L libssl1.0-dev:i386 | grep openssl.pc
> /usr/lib/i386-linux-gnu/pkgconfig/openssl.pc
>
> Should CMake not use CMAKE_LIBRARY_ARCHITECTURE?  Is there some neat work
> around?  Best I can now think of is to create a script pkg-config.i386,
> make that set the proper search path and tell CMake to use this script :(
>
> Thanks --- Jan
>
>

-- 

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] FindPkgConfig and using -m32 on Linux

2019-01-17 Thread Jan Wielemaker
Hi,

I'm trying to build a complicated package for 32-bits on 64-bit Ubuntu.
I got very far using

set(CMAKE_C_FLAGS -m32)
set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu)

But right now, find_package(OpenSSL) is failing.  I think the problem is
with FindOpenSSL.cmake doing this (Ubuntu 18.04, CMake 3.10):

if (UNIX)
  find_package(PkgConfig QUIET)
  pkg_check_modules(_OPENSSL QUIET openssl)
endif ()

Ubuntu has, I think compatibe with the Linux standard, these .pc files
for the multilib installed OpenSSL:

$ dpkg -L libssl1.0-dev | grep openssl.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc
$ dpkg -L libssl1.0-dev:i386 | grep openssl.pc
/usr/lib/i386-linux-gnu/pkgconfig/openssl.pc

Should CMake not use CMAKE_LIBRARY_ARCHITECTURE?  Is there some neat work
around?  Best I can now think of is to create a script pkg-config.i386,
make that set the proper search path and tell CMake to use this script :(

Thanks --- Jan


-- 

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:
https://cmake.org/mailman/listinfo/cmake