Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree
Hello Brad, On 30/07/14 15:32, Brad King wrote: Thanks. While reviewing the commits in 'next' again I realized that assuming paths are relative to CMAKE_BINARY_DIR may not be correct. Some projects may be nested inside others, and the CMAKE_BINARY_DIR may not be the proper location for a nested project. Instead the BUILD_TREE option should be followed by another argument specifying the base for relative paths, i.e. the in-build-tree prefix. I updated the CMakePackageConfigHelpers_build_tree with the requested changed, I'm not sure how to handle this, since the branch is already merged in next, so I added 2 commits that can be squashed to the previous ones: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=fcdb23e0 http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=77e64799 Can you please review the changes and tell me if I can merge them to next? Thanks. Cheers, Daniele -- 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] [PATCH] Fix broken PGI builds for liblzma.
I noticed the recent merge of liblzma broke the PGI compiler. The attached
patch should address the issues:
PGC-S-0037-Syntax error: Recovery attempted by deleting keyword static
(/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:
84)
Once that's fixed, then the 32-bit build works but the 64-bit build is
still broken with:
../Utilities/cmliblzma/libcmliblzma.a(sha256.c.o): In function
`lzma_sha256_finish':
/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:196:
undefined reference to `__bswap_64'
The patch should address both issues with explanations as to why.
- Chuck
From 4c33d91f999b9030b4666be2f94d7a86c8da8527 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Fri, 1 Aug 2014 13:56:41 -0400
Subject: [PATCH] Fix broken PGI builds for liblzma.
- sha265.c is using some C99 specific features, in particular static
array dimensions in a function parameter array (see section 6.7.5-7
of the C99 spec). A #ifndef check was in place to prevent compilation
under MSVC but it actually needs to check for C99 compliance instead.
Also, even though the PGI C compiler reports to be fully C99 compliant,
it still fails.
- CHECK_SYMBOL_EXISTS is used to determine the presense of bswap
functions from byteswap.h. Most compilers re-dedefine the bswap_N
functions as a __bswap_N function implemented by the compiler. Since
bswap_N is usually defined as a macro then it's mere presence passes
the check. Some versions of the PGI compiler though have shipped
broken headers for byteswap.h, in particular 11.3 for x64 linux
provides byteswap.h but is missing an associated bits/byteswap.h which
causes some of the bswap_N macros to be defined but broken and unusable.
The bswap_N checks have been converted to CHECK_SOURCE_COMPILES to
ensure that the bswap_N calls are actually usable and not just merely
defined.
---
Utilities/cmliblzma/CMakeLists.txt | 12 +---
Utilities/cmliblzma/liblzma/check/sha256.c |4 +++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Utilities/cmliblzma/CMakeLists.txt b/Utilities/cmliblzma/CMakeLists.txt
index fc50dbe..856e41e 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -31,9 +31,15 @@ CHECK_INCLUDE_FILE(strings.h HAVE_STRINGS_H)
CHECK_INCLUDE_FILE(string.h HAVE_STRING_H)
CHECK_INCLUDE_FILE(sys/sysctl.h HAVE_SYS_SYSCTL_H)
-CHECK_SYMBOL_EXISTS(bswap_16 byteswap.h HAVE_BSWAP_16)
-CHECK_SYMBOL_EXISTS(bswap_32 byteswap.h HAVE_BSWAP_32)
-CHECK_SYMBOL_EXISTS(bswap_64 byteswap.h HAVE_BSWAP_64)
+CHECK_C_SOURCE_COMPILES (
+ #includebyteswap.h\nint main(void){bswap_16(0);return 0;}
+ HAVE_BSWAP_16)
+CHECK_C_SOURCE_COMPILES (
+ #includebyteswap.h\nint main(void){bswap_32(0);return 0;}
+ HAVE_BSWAP_32)
+CHECK_C_SOURCE_COMPILES (
+ #includebyteswap.h\nint main(void){bswap_64(0);return 0;}
+ HAVE_BSWAP_64)
TEST_BIG_ENDIAN(WORDS_BIGENDIAN)
diff --git a/Utilities/cmliblzma/liblzma/check/sha256.c b/Utilities/cmliblzma/liblzma/check/sha256.c
index b09ccbf..f1d3337 100644
--- a/Utilities/cmliblzma/liblzma/check/sha256.c
+++ b/Utilities/cmliblzma/liblzma/check/sha256.c
@@ -80,7 +80,9 @@ static const uint32_t SHA256_K[64] = {
static void
-#ifndef _MSC_VER
+#if defined(__STDC_VERSION__) (__STDC_VERSION__ 199901L) \
+ !defined(__PGIC__)
+/* Even though int foo[static 3] is valid C99, the PGI compiler still breaks */
transform(uint32_t state[static 8], const uint32_t data[static 16])
#else
transform(uint32_t state[], const uint32_t data[])
--
1.7.4.1
--
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] Fix broken PGI builds for liblzma.
It should be noted that the patch is really a set of workaround for PGI compiler being broken and less to do with the code itself. If desired, I could refactor the #if C99 test to use a CHECK_SOURCE_COMPILES at the CMake level instead. - Chuck On Fri, Aug 1, 2014 at 2:22 PM, Chuck Atkins chuck.atk...@kitware.com wrote: I noticed the recent merge of liblzma broke the PGI compiler. The attached patch should address the issues: PGC-S-0037-Syntax error: Recovery attempted by deleting keyword static (/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c: 84) Once that's fixed, then the 32-bit build works but the 64-bit build is still broken with: ../Utilities/cmliblzma/libcmliblzma.a(sha256.c.o): In function `lzma_sha256_finish': /home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:196: undefined reference to `__bswap_64' The patch should address both issues with explanations as to why. - Chuck -- 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] Fix broken PGI builds for liblzma.
On 08/ 2/14 01:27 AM, Chuck Atkins wrote: It should be noted that the patch is really a set of workaround for PGI compiler being broken and less to do with the code itself. If desired, I could refactor the #if C99 test to use a CHECK_SOURCE_COMPILES at the CMake level instead. I'm not intimately following this issue, but I can get you access to pathcc/pathCC to see if we work on this as well. I have no idea why anyone would want to use PIG to compile cmake, but... (C99 doesn't work correctly on some of the older linux) So while c99 is claimed to be supported - it was in fact broken. SLES10 is one example I know 1st hand - there are others as well. So while we support c99 on SLES11 - it gets disabled on older linux. feature/functional tests imho are always preferred vs #if.. -- 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] Fix broken PGI builds for liblzma.
On Fri, Aug 1, 2014 at 2:43 PM, C. Bergström cbergst...@pathscale.com wrote: I'm not intimately following this issue, but I can get you access to pathcc/pathCC to see if we work on this as well. I've got an older ekopath 4.0.9 and 4.0.10 install that you gave us a while back when I was setting up some LAPACK testing. The build was fine without this patch so no issues there. It would be nice to get an updated version though going on a nightly dashboard. Let's discuss further off-list. (C99 doesn't work correctly on some of the older linux) So while c99 is claimed to be supported - it was in fact broken. SLES10 is one example I know 1st hand - there are others as well. In this particular case it's a C99 language feature not library or include issue so I wouldn't expect the OS version to matter but I suppose could. We've seen similar issues with trying to use AVX instructions on RHEL5. MAny compilers will detect the CPU as supporting it and try to generate the code but the kernel doesn't support the instructions and will segfault so we need to explicitly disable AVX optimizations on RHEL5. feature/functional tests imho are always preferred vs #if.. If the if C99 tests are actually reliable and I could trust that C99 would work then I'd rather since it really bogs down the configure time. That being said though, in this case it seems to not be since __STDC_VERSION__ is getting set to 199901L by the compiler but clearly not all C99 features are working. -- 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] /MP[num_threads] not working in Cmake 3.0.0
Hello Brad,
You are right. It is working fine. My fault configuring the options.
Thank you and sorry for this.
On Thu, Jul 31, 2014 at 5:39 PM, Brad King brad.k...@kitware.com wrote:
On Thu, Jul 31, 2014 at 10:29 AM, Jaime Armendariz wrote:
If I add /MP4 for example in my${CMAKE_CXX_FLAGS_RELEASE}, cmake
converts
it to /MP that means all cores available.
[snip]
Cmake 3.0.0 and 2.8.12.2
Windows 7 64 bits
Visual Studio 2013 / Visual Studio 2010 SP1
With CMake 3.0.0 on VS 2013 I tried that and got:
MultiProcessorCompilationtrue/MultiProcessorCompilation
ProcessorNumber4/ProcessorNumber
in the .vcxproj file. The compilation command-line then had /MP4
as expected.
-Brad
--
* Jaime Armendariz Villalba*Software Director / Information Systems Director
Aurora Software and Testing, S. L.
Universidad Politécnica de Valencia
Edificio de Desarrollo Empresarial 9B
Camino de Vera, s/n, 46022
Valencia, Spain
Tlf: +34 963 714 254
--
La información contenida en este correo electrónico, y en su caso,
cualquier fichero anexo al mismo, son de carácter privado y confidencial
siendo para uso exclusivo de su destinatario. Si usted no es el
destinatario correcto, el empleado o agente responsable de entregar el
mensaje al destinatario, o ha recibido esta comunicación por error, le
informamos que está totalmente prohibida cualquier divulgación,
distribución o reproducción de esta comunicación según la legislación
vigente y le rogamos que nos lo notifique inmediatamente, procediendo a su
destrucción sin continuar su lectura.
Le informamos que su dirección de correo electrónico, así como el resto de
los datos de carácter personal que nos facilite, podrían ser objeto de
tratamiento automatizado en nuestros ficheros, con la finalidad de
gestionar la agenda de contactos de nuestra empresa. Vd. podrá en cualquier
momento ejercer el derecho de acceso, rectificación, cancelación y
oposición en los términos establecidos en la Ley Orgánica 15/1999 de
Protección de Datos de Carácter Personal mediante notificación a esta
dirección de correo electrónico.
--
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
Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake
Hi David,
We are executing the following POST_BUILD commands using add_custom_command()
call in cmake.
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD COMMAND ${TBIN}/VerCheck.exe \$(TargetPath)\
POST_BUILD COMMAND copy \$(TargetPath)\
\$(TargetPath).vercheck_dummy_target\
COMMENT Checking if $(TargetPath) has version info...)
The issue we are facing is with the execution of the post-build command
${TBIN}/VerCheck.exe \$(TargetPath)\. It gives the following error:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error
MSB3073: The command setlocal\r [E:\RaviRaman\Project\Auto
Desk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj]
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error
MSB3073: ..\..\..\..\..\..\..\develop\tools\bin\VerCheck.exe
E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\Debug\GenVerInfo_d.exe\r
[E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj]
Also, note the following:
1. The execution is successful and there is no error when I keep only the copy
command and comment out the command ${TBIN}/VerCheck.exe \$(TargetPath)\
2. VerCheck.exe is a project specific executable which checks the version of
the specified target
3. All the variables above in ${...} are getting correctly replaced. So, that
is not an issue.
4. We are able to execute both the commands ${TBIN}/VerCheck.exe and copy
successfully from the DOS command line.
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip
Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com| http://www.xoriant.com
-Original Message-
From: Ravi Raman
Sent: Thursday, July 31, 2014 5:07 PM
To: 'David Cole'
Cc: cmake@cmake.org
Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio
.targets files to cmake
Hi David,
Thanks for the reply. Understood.
Will use the cmake function add_custom_command() with POST_BUILD option in case
of after build and PRE_BUILD option in case of before build.
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip
Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com| http://www.xoriant.com
-Original Message-
From: David Cole [mailto:dlrd...@aol.com]
Sent: Thursday, July 31, 2014 4:55 PM
To: Ravi Raman
Cc: cmake@cmake.org
Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio
.targets files to cmake
So from the example you've sent, it seems like the stuff in your
targets file is just a bunch of custom commands that you'd need to run.
There are plenty of examples of projects using add_custom_command and
add_custom_target out there, and if you have specific questions about
how those commands work, do send more emails and ask those questions.
I don't think there's anything out there that will help you automate
this task but if there is, hopefully somebody who can point you to
them will show up here.
Otherwise, it's just roll up your sleeves time, and do the work
manually to convert targets files into CMakeLists that use
add_custom_command.
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/mailman/listinfo/cmake
Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake
First try this:
-Original Message-
From: Ravi Raman ravi.ra...@xoriant.com
To: David Cole dlrd...@aol.com
Cc: cmake cmake@cmake.org
Sent: Fri, Aug 1, 2014 7:49 am
Subject: RE: [CMake] Cmake issue regarding conversion of existing
Visual Studio .targets files to cmake
Hi David,
We are executing the following POST_BUILD commands using
add_custom_command() call in cmake.
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD COMMAND ${TBIN}/VerCheck.exe \$(TargetPath)\
POST_BUILD COMMAND copy \$(TargetPath)\
\$(TargetPath).vercheck_dummy_target\
COMMENT Checking if $(TargetPath) has version info...)
The issue we are facing is with the execution of the post-build command
${TBIN}/VerCheck.exe \$(TargetPath)\. It gives the following error:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: The command setlocal\r [E:\RaviRaman\Project\Auto
Desk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\glob
al\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj]
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: ..\..\..\..\..\..\..\develop\tools\bin\VerCheck.exe
E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\X
oriantRepo\components\global\src\objectdbx\build\x64\versioninfo\Debug\Ge
nVerInfo_d.exe\r
[E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\X
oriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerIn
fo.vcxproj]
Also, note the following:
1. The execution is successful and there is no error when I keep only
the copy command and comment out the command ${TBIN}/VerCheck.exe
\$(TargetPath)\
2. VerCheck.exe is a project specific executable which checks the
version of the specified target
3. All the variables above in ${...} are getting correctly replaced.
So, that is not an issue.
4. We are able to execute both the commands ${TBIN}/VerCheck.exe and
copy successfully from the DOS command line.
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076,
INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98
Voip Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com| http://www.xoriant.com
-Original Message-
From: Ravi Raman
Sent: Thursday, July 31, 2014 5:07 PM
To: 'David Cole'
Cc: cmake@cmake.org
Subject: RE: [CMake] Cmake issue regarding conversion of existing
Visual Studio .targets files to cmake
Hi David,
Thanks for the reply. Understood.
Will use the cmake function add_custom_command() with POST_BUILD option
in case of after build and PRE_BUILD option in case of before build.
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076,
INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98
Voip Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com| http://www.xoriant.com
-Original Message-
From: David Cole [mailto:dlrd...@aol.com]
Sent: Thursday, July 31, 2014 4:55 PM
To: Ravi Raman
Cc: cmake@cmake.org
Subject: Re: [CMake] Cmake issue regarding conversion of existing
Visual Studio .targets files to cmake
So from the example you've sent, it seems like the stuff in your
targets file is just a bunch of custom commands that you'd need to run.
There are plenty of examples of projects using add_custom_command and
add_custom_target out there, and if you have specific questions about
how those commands work, do send more emails and ask those questions.
I don't think there's anything out there that will help you automate
this task but if there is, hopefully somebody who can point you to
them will show up here.
Otherwise, it's just roll up your sleeves time, and do the work
manually to convert targets files into CMakeLists that use
add_custom_command.
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/mailman/listinfo/cmake
Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake
Sorry about the premature send on that last email...
First try this:
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD
COMMAND ${TBIN}/VerCheck.exe \$(TargetPath)\
COMMAND copy \$(TargetPath)\
\$(TargetPath).vercheck_dummy_target\
COMMENT Checking if $(TargetPath) has version info...)
i.e. -- just say POST_BUILD once, then a sequence of COMMAND lines.
(I think it's passing your second POST_BUILD as an argument to
VerCheck...)
If that still doesn't work, try:
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD
COMMAND VerCheckAndCopy.bat ${TBIN} $(TargetPath)
COMMENT Checking if $(TargetPath) has version info...)
and delegate it to a batch script that takes arguments which internally
does the sequence of commands you want. If you go this route, you may
still need nested quotes around $(TargetPath) -- CMake doesn't know
about expanding those VS values, and whether or not they'll need quotes
around them.
HTH,
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/mailman/listinfo/cmake
Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake
Hi David,
Thanks. The 2nd approach of using batch file worked successfully.
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip
Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com| http://www.xoriant.com
-Original Message-
From: David Cole [mailto:dlrd...@aol.com]
Sent: Friday, August 01, 2014 5:41 PM
To: Ravi Raman
Cc: cmake@cmake.org
Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio
.targets files to cmake
Sorry about the premature send on that last email...
First try this:
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD
COMMAND ${TBIN}/VerCheck.exe \$(TargetPath)\
COMMAND copy \$(TargetPath)\
\$(TargetPath).vercheck_dummy_target\
COMMENT Checking if $(TargetPath) has version info...)
i.e. -- just say POST_BUILD once, then a sequence of COMMAND lines.
(I think it's passing your second POST_BUILD as an argument to
VerCheck...)
If that still doesn't work, try:
add_custom_command(
TARGET ${TARGETNAME}
POST_BUILD
COMMAND VerCheckAndCopy.bat ${TBIN} $(TargetPath)
COMMENT Checking if $(TargetPath) has version info...)
and delegate it to a batch script that takes arguments which internally
does the sequence of commands you want. If you go this route, you may
still need nested quotes around $(TargetPath) -- CMake doesn't know
about expanding those VS values, and whether or not they'll need quotes
around them.
HTH,
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/mailman/listinfo/cmake
[CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS
Hi, I am building a library containing Fortran and C sources. I would like to add language specific compile flags without affecting the global compile flags: set_target_properties( foo PROPERTIES C_FLAGS -fopenmp Fortran_FLAGS -openmp ) However, it seems there is only COMPILE_FLAGS which presumably affects both languages. Thanks already, nick -- 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
Re: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS
Hi Nick,
You could split your target in to two object libraries that combine into a
singe real library:
add_library(foo_f OBJECT ${FOO_F_SOURCES})
# set necessary compile flags specific to the Fortran components
# on the foo_f target
add_library(foo_c OBJECT ${FOO_C_SOURCES})
# set necessary compile flags specific to the C components
# on the foo_c target
# Combine into a real library
add_library(foo $TARGET_OBJECTS:foo_f $TARGET_OBJECTS:foo_c)
See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
- Chuck
On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock nicolasb...@gmail.com wrote:
Hi,
I am building a library containing Fortran and C sources. I would like
to add language specific compile flags without affecting the global
compile flags:
set_target_properties( foo PROPERTIES C_FLAGS -fopenmp Fortran_FLAGS
-openmp )
However, it seems there is only COMPILE_FLAGS which presumably affects
both languages.
Thanks already,
nick
--
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
--
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
[CMake] Defining a function in a macro
Hey List -
Just wanted to put this out there for posterity, and in case anyone runs
into the same question I had. I had a bunch of nearly identical
functions, so I wanted to write a function to define them for me to
reduce code repetition. The problem I ran into was that if you write
macro(_define_function name)
function(namespaced_${function_name} ...)
message(${ARGV} from ${name})
endfunction()
endmacro()
_define_function(foo)
namespaced_foo(Message)
you actually wind up printing foo from foo, since all variable
references to a macro are expanded first. I also couldn't use a
function, since there would be no way to access ${name} from inside the
function (that I'm aware of - please correct me on this if I'm wrong)
The solution I came up with was, if I wanted to reference the function's
argv, I would do a double-dereference of a string containing ARGV like so:
macro(_define_function name)
function(namespaced_${function_name} ...)
set(my_argv ARGV)
message(${${my_argv}} from ${name})
endfunction()
endmacro()
This produced the correct results. If any of you know of a cleaner way
to do this, I'd love to hear about it. If not, have fun writing
functions to write your functions!
As a relatively useless, but I thought entertaining aside:
macro(_define_function name my_argv)
function(namespaced_${function_name} ...)
message(${my_argv} from ${name})
endfunction()
endmacro()
_define_function(foo \${ARGV})
namespaced_foo(Message)
The result is foo Message from foo because ${my_argv} gets expand to
${ARGV}, which then expands to foo ${ARGV}.
Thanks!
--
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
