Re: [CMake] [cmake-developers] Identify used source files

May be more clean and efficient to use CMake property SOURCES: For example: add_library (MY_LIB src1.cpp src2.cpp) get_target_property (lib_sources MY_LIB SOURCES) And variable lib_sources now contains list of sources associated with target. On 28/04/15 10:30, Roman Wüger

Re: [CMake] Alias of imported target

but it is, by far, less elegant and coherent with target handling. On 05/05/15 19:01, Stephen Kelly steve...@gmail.com wrote: CHEVRIER, Marc wrote: Hi, Currently it is not possible to create an alias target for an imported target (I.e. add_library with ALIAS keyword). But I don’t understand what

[CMake] Alias of imported target

Hi, Currently it is not possible to create an alias target for an imported target (I.e. add_library with ALIAS keyword). But I don’t understand what is the technical constraint or semantic reason behind this limitation. If anybody can explain this limitation, it will be nice. -- Powered by

Re: [CMake] How URL_MD5 is computed in ExternalProject_Add?

You can use FILE (MD5 file variable) command to compute MD5 value. From: CMake on behalf of Cedric Doucet Date: Tuesday 19 May 2015 13:14 To: cmake@cmake.orgmailto:cmake@cmake.org Subject: Re: [CMake] How URL_MD5 is computed in ExternalProject_Add? I managed to obtain the same MD5 code by

Re: [CMake] Setting install dir based on Debug or Release

Multi-configurations is a bit complex to handle regarding install directories but it is doable. Here is my solution: 1. Handle various possibilities (multi-configs or mono-config). In case of multi-config, you have to rely on variable CMAKE_CFG_INTDIR which be contains information enabling

Re: [CMake] How to link archives (.a) into shared object (.so) with cmake ?

Hi, Shared libraries required position independent code (PIC) for objects. By default, in CMake, static libraries objects are not compiled with this mode… So your problem. The easiest solution is to add this line to your CMakeLists.txt file: Set (CMAKE_POSITION_INDEPENDENT_CODE ON) Marc

Re: [CMake] How to link archives (.a) into shared object (.so) with cmake ?

rg on behalf of hous...@ipgp.fr> wrote: >Unfortunately, that does not work !... But indeed, for me, it should >have ?!... > >Franck > >Le 2015-11-17 12:34, CHEVRIER, Marc a écrit : >> Hi, >> >> Shared libraries required position independent code (PIC) for &

Re: [CMake] Prefix header for Makefiles

Hi, You are wrong. CMake, during configuration/generation phase generates dependencies over C/C++ files. So, the simple approach to handle dependency between Cpp and h files is to let CMake handle it: add_executable (my_exe Main.cpp) And, that it! By default current source directory is passed

Re: [CMake] Patch on Windows?

FYI, the latest version (2.5.1) of git for Windows (available https://github.com/git-for-windows/git/releases and http://git-scm.com/) includes again the patch tool. Marc From: CMake on behalf of "Macumber, Daniel" Date: Tuesday 1 September 2015 17:51 To:

Re: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY

PROJECT instruction MUST BE the first one after CMAKE_MINIMUM_REQUIRED: -- lib CMakeLists.txt { CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8) PROJECT(lib) ADD_SUBDIRECTORY(libtest) } From: CMake on behalf of Emmanuel HOUITTE Date: Friday 11 September 2015 15:26 To:

[CMake] How to check if test exists

Hi, What is the best way to check if a test is already defined using function add_test? My initial though was that if() can be used for that purpose but, unfortunately, if (TEST ) is not supported for now. Thanks. Marc -- Powered by www.kitware.com Please keep messages on-topic and

Re: [CMake] CMake and a simple java example

Hi, You didn’t specify nothing in variable JAVA_SOURCE_DIRECTORY, so java source path is effectively /HelloWorld.java. By the way, you can specify relative paths to the CMakeLists.txt directory for java sources, so: set(JAVA_SOURCE_FILES HelloWorld.java) add_jar(${JAR_NAME}

Re: [CMake] How to generate for Ninja + MSVC?

Alternate solution is to define following environment variables: * CC=cl.exe * CXX=cl.exe In this case, CMake will search these compilers rather than the standard choices (starting with c++ and g++ for C++ language). And you don’t have any longer constraints about your environment. Marc

Re: [CMake] ExternalProject_Add and inheritance

The problem is not a CMake one but a runtime environment one. You built an executable with a specific environment (GCC 5) but try to execute it in a different environment (default platform): When an executable is built, system libraries paths are not stored as part of the executable so without

Re: [CMake] ExternalProject_Add and inheritance

With CMake, you can control compilation and link flags with the following environment variables: * CC: specify C compiler * CFLAGS: C compiler flags * CXX: specify C++ compiler * CXXFLAGS: C++ compiler flags * LDFLAGS: linker flags And to finish you can overload make command

Re: [CMake] find_library

Defining a variable using -D option does not put this one in the environment (i.e. system environment) so using ENV will fails... On 14/01/16 10:28, "CMake on behalf of Vania Joloboff" wrote: >I am running cmake 3.2.2 on Linux

Re: [CMake] test endian ness

Hi, May be to include the module before using it: include (TestBigEndian) On 13/01/16 15:25, "CMake on behalf of Vania Joloboff" wrote: >Hi > >I am familiar with autoconf and trying to migrate our project to cmake. >Thus

Re: [CMake] Adding definitions to compile one file ?

Use APPEND keyword: set_property( SOURCE source.cpp APPEND PROPERTY COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} ) On 21/01/16 15:26, "CMake on behalf of Vania Joloboff" wrote: >HI Petr > >Thanks for the

Re: [CMake] string regexp replace removes the semicolons

Hi, Command file(GLOB) returns a CMake list (in a CMake list, items are separated by ;) Now you pass to command string the content of the list, so the list is expanded: in your example, string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES}) Is equivalent to: string(REGEX REPLACE

Re: [CMake] File names with unbalanced square brackets

I think you can resolve your problem with the following syntax for foreach command: Foreach (FILE IN LISTS FILES) In this case the list is not expanded in your source so square brackets is no longer interpreted… From: CMake > on behalf

[CMake] CTest usage

Hi, Is there someone able to help me regarding ctest usage with labels? Here is the problem: I have various tests which have labels attached to them: set_property (TEST test1 PROPERTY LABELS LABEL1) set_property (TEST test2 PROPERTY LABELS LABEL1 LABEL2) set_property (TEST test3 PROPERTY LABELS

Re: [CMake] Build from Source on Solaris

iltin_signbitl" must have a prototype. "/opt/solarisstudio12.4/lib/compilers/CC-gcc/include/c++/4.8.2/cmath", line 562: Error: std::fpclassify(float) already had a body defined. ``` Cheers, Matt On Wed, Mar 2, 2016 at 9:54 AM, CHEVRIER, Marc <marc.chevr...@sap.com<mailto:marc.ch

Re: [CMake] Build from Source on Solaris

Hi, Some help can be found in this thread: http://public.kitware.com/pipermail/cmake-developers/2015-September/026550.html Marc From: CMake > on behalf of Matthew Gidden > Date:

Re: [CMake] project command not working, when used via macro (from an included file)

May be using keyword NO_POLICY_SCOPE in include command will solve your problem… From: CMake > on behalf of Chuck Atkins > Date: Tuesday 26 April 2016 at 20:04 To: aj neu

Re: [CMake] add_compile_options query

Specify flags as strings rather than lists (i.e. add quotes): add_compile_options("--param l1-cache-size=24") add_compile_options("--param l1-cache-line-size=64") add_compile_options("--param l2-cache-size=512") On 12/08/16 11:08, "CMake on behalf of Alex Biddulph"

Re: [CMake] Use GLOB to generate filelist for install package

Remove the quotes around the variable MY_INCLUDES_H in the INSTALL command because this is a list. Using quotes, you pass it as a single string. On 11/08/16 11:03, "CMake on behalf of Patrik Lehmann" wrote: Hello,

Re: [CMake] setting environment variable for ctest

Use the ENVIRONMENT property of your tests (see https://cmake.org/cmake/help/v3.7/prop_test/ENVIRONMENT.html). On 05/05/2017, 16:29, "CMake on behalf of Juan E. Sanchez" wrote: Hello, It appears that when I invoke

Re: [CMake] Adding compile and build type tests to CMake/CTest

Yes, exactly. I think so… On 07/09/2017, 16:04, "CMake on behalf of Edward Diener" <cmake-boun...@cmake.org on behalf of eldlistmaili...@tropicsoft.com> wrote: On 9/7/2017 3:32 AM, CHEVRIER, Marc wrote: > Rather than building a STATIC library, you can buil

Re: [CMake] Adding compile and build type tests to CMake/CTest

Rather than building a STATIC library, you can build an OBJECT library. In this case only compilation step is done. On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" wrote: On 9/6/2017 11:39 PM, P F via CMake

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

work as well. From: Saad Khattak <saadrus...@gmail.com> Date: Saturday 16 December 2017 at 00:39 To: "CHEVRIER, Marc" <marc.chevr...@sap.com> Cc: Craig Scott <craig.sc...@crascit.com>, Cmake Mailing List <cmake@cmake.org> Subject:

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

I think you can fill a bug about erroneous behaviour when a list is specified with command set_target_properties for property IMPORTED_LINK_INTERFACE_LIBRARIES. Another way to specify the property is to use command set_property which supports multiple values for a property: set_property(TARGET

Re: [CMake] configure_file: escaping (single) quotes

Yes, you have to rewrite your line as: CMD="mpirun -n @MPIEXEC_PREFLAGS@ @MPIEXEC_NUMPROC_FLAG@ @MPIEXEC_MAX_NUMPROCS@ @MPIEXEC_POSTFLAGS@" From: Franck Houssen <franck.hous...@inria.fr> Date: Tuesday 9 January 2018 at 11:23 To: "CHEVRIER, Marc" <marc.chevr...

Re: [CMake] configure_file: escaping (single) quotes

The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR…}) and detect wrong syntax. The solution is to specify option @ONLY to command configure_file to avoid ${} evaluation. From: CMake on behalf of Franck Houssen Date:

Re: [CMake] Get find_package to choose INSTALLed libraries instead of libraries in the build folder

Hi, During install step, installed libraries and executables are relinked to generate binaries without absolute paths so installed artifacts are independent from your build tree. During build step, build binaries are used as well as absolute paths so produced binaries can be used during build

Re: [CMake] How to add files to Visual Studio 'Utility' project

This approach is not possible for Java because the command add_jar is implemented using commands add_custom_command and add_custom_target. And command target_sources implies that the target was created by one the commands add_library or add_executable. From: CMake on

Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH

Be aware that MSYS2 environment is a "dual" environment: * Unix like environment. Executables are in /usr/bin * Windows like (i.e. understand windows paths but with slashes rather than back-slashes). Executables are in / mingw(64|32)/bin. So, if you want a pure unix like usage, you have to

Re: [CMake] Source file property INCLUDE_DIRECTORIES

Because this property is not yet supported for source files (see #17507). FYI, I worked on this support and the merge request is under process… (see !1596). From: CMake

Re: [CMake] Source file property INCLUDE_DIRECTORIES

Sure. APPEND keyword is handled at a high level (i.e. regardless the property evolved). From: J Decker <d3c...@gmail.com> Date: Friday 12 January 2018 at 15:03 To: "CHEVRIER, Marc" <marc.chevr...@sap.com> Cc: CMake Mail List <cmake@cmake.org> Subject: Re:

Re: [CMake] Generator expression for "is in list"?

Operator IN_LIST in generator expressions will be available in CMake version 3.12, (i.e. the next version). In the meantime, I am afraid there is no solution in the context of generator expressions. However, you can directly use the contents of the property in your CMakeLists.txt. Example:

Re: [CMake] find_package and get_target_property

The creation of “imported” target is the responsibility of the package. May be the package “LibA” does not create a such target. In this case, you have to rely on variables (like LibA_LIBRARIES and so on…). The documentation of the package, if any, generally describe how to use the package.

Re: [CMake] find_package and get_target_property

15:02 To: "CHEVRIER, Marc" <marc.chevr...@sap.com> Subject: Re: [CMake] find_package and get_target_property Ah I see. In this case, the Libraries I'm depending on are generated, built and installed using CMake. I'm hoping that CMake is able to generate the Find.cmake for me with the approp

Re: [CMake] swig module add -fPIC flag

swig modules created with command SWIG_ADD_LIBRARY are "standard" CMake targets so, same approach apply. >From convenience, you can use command SWIG_LINK_LIBRARIES (same semantic as >TARGET_LINK_LIBRARIES) to manage custom link flags. Now, regarding specifically flag -fPIC you can manage

Re: [CMake] Generator expressions containing spaces

The space is used to separate arguments passed to COMMAND. So your generator expression is splitted before evaluation and elements are no longer valid generator expression. So, to solve your problem, encapsulate the generator expression inside quotes. And apply the following advices for

Re: [CMake] find_package() for static only / shared only

criminated from the static library. Is there a good solution for MSVC too? All the best, Mario On 22.03.2018 09:41, CHEVRIER, Marc wrote: > Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. > For example, on

Re: [CMake] find_package() for static only / shared only

Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES. For example, on linux: * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so") * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a") On Windows, it is more problematic because static and "import" shared libraries have

Re: [cmake-developers] Java support

Thank you. Unfortunately I don’t have access to an HP-UX system. From what I remember, HP-UX expect shared libraries with same name pattern as Linux except that extension is .sl rather than .so. Marc On 14/08/15 15:45, Brad King brad.k...@kitware.com wrote: On 08/07/2015 04:04 AM, CHEVRIER

[cmake-developers] Java support

Hi, Here are some patches to enhance Java support. 0001 (FindJava.cmake): Defines now two new variables for idlj and jar signer tools: Java_IDLJ_EXECUTABLE and Java_JARSIGNER_EXECUTABLE 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java sources specification. 0003

Re: [cmake-developers] Java support

I just detected a small error introduced in patch 0001, here is the correct version. Sorry for the noise... On 30/07/15 11:32, cmake-developers on behalf of CHEVRIER, Marc cmake-developers-boun...@cmake.org on behalf of marc.chevr...@sap.com wrote: New version of patches taking

Re: [cmake-developers] Java support

Thanks. I will have a look for the patch 4. Marc On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote: On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote: New version of patches. Thanks. I applied the first three with minor tweaks and merged to 'next' for testing: FindJava: Add support

Re: [cmake-developers] Java support

Attached is a new version of patch 4 tested successfully on Linux (SuSE 11.3), Windows (7 64bit) and MacOS (10.10.4) Marc On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote: On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote: New version of patches. Thanks. I applied the first three

Re: [cmake-developers] Java support

-boun...@cmake.org on behalf of e...@sf-mail.de wrote: Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc: Hi, 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java sources specification. You do not need leading or trailing .* in regular expressions. In fact I

Re: [cmake-developers] Java support

OK. New version of patches. There is now a component per extra tool (for now IdlJ and JarSigner as suggested by Brad) to ensure future extensibility. Marc On 30/07/15 16:49, Brad King brad.k...@kitware.com wrote: On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote: here is the correct version

Re: [cmake-developers] Java support

will require some explicit check to ensure these tools are found before usage. Regarding your second remark, I will update my patches. Marc On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote: On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: here is an updated list of patches. Great

Re: [cmake-developers] Java support

New version of patches taking into account Brad’ remarks. Marc On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote: On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: here is an updated list of patches. Great. find_package_handle_standard_args(Java REQUIRED_VARS

Re: [cmake-developers] Java support

Hi, New version of patch attached. I added a check on java tool to execute test only if java and shared library built by test have same architecture (32 or 64bit). Marc On 05/08/15 17:49, Brad King brad.k...@kitware.com wrote: On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote: For point 2

Re: [cmake-developers] Java support

in the PATH. In this case, CMake FindJava.cmake module will look at the registry to retrieve the correct java version. Marc On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote: On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote: Attached is a new version of patch 4 tested successfully

Re: [cmake-developers] Java support

Hi, Again, a new version for patch 4. I hope I didn’t miss anything this time. :) To handle VS generators, I am relying on generator-expressions supported by add_test function. Marc On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote: On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote

[cmake-developers] [PATCH][CMAKE] C sources must use C Style comments

Hi, Attached is a small patch ensuring that c source is compiling even if C compiler (AIX xlc for example) does not support C++ Style comments. Marc 0001-Use-C-Style-comments-in-C-sources.patch Description: 0001-Use-C-Style-comments-in-C-sources.patch -- Powered by www.kitware.com Please

Re: [cmake-developers] CXX_STANDARD and linking

No problem for me to keep broken behavior of SolarisStudio. Let me know when C++ Standard support including linking part is implemented, I can help you to validate it on Solaris SPARC. Thanks. Marc On 08/10/15 19:24, "cmake-developers on behalf of Brad King"

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

I agree with David. Offering the possibility to manage native paths in an easy way is a very good enhancement (Today, I rely on some specific actions when I am on Win32 to manage native path for ONE specific step of ExternalProject) BUT, offering only the alternative to have NONE or ALL paths

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

Offering generator-expressions is a very good idea because it offers a global solution to this problem. Now regarding the name of the generator, may be TO_NATIVE_PATH is not judicious, (even if problems explained in http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to

Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)

commands should be a nice enhancement. Marc On 28/08/15 15:59, cmake-developers on behalf of Brad King cmake-developers-boun...@cmake.org on behalf of brad.k...@kitware.com wrote: On 08/28/2015 04:06 AM, CHEVRIER, Marc wrote: Offering generator-expressions is a very good idea because

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

you prefer to have a switch for each *_DIR variable for all target steps, or a common switch but for each target step, like the new USE_TERMINAL switches in the master? Von: CHEVRIER, Marc [marc.chevr...@sap.com] Gesendet: Mittwoch, 26. August 2015 08:49

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

/gen Marc On 02/09/15 17:44, "Brad King" <brad.k...@kitware.com> wrote: >On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote: >> On 02/09/15 14:58, "Brad King" wrote: >>> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >>>> find_program (MY_EXE my_e

[cmake-developers] [BUG] HINTS not correctly handled in find_program

Hi, I discovered a curious problem regarding handling of argument HINTS. If I use the following command: find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) And my_exe is available in various paths. In this case, paths specified in HINTS AND also defined in environment variable PATH are

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

Same problem. HINTS which are also defined in the environment variable PATH are ignored. On 02/09/15 14:58, "Brad King" <brad.k...@kitware.com> wrote: >On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) > &

[cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

Hi, To enable to handle various packages as part of the same project and to avoid to execute preinstall target before packaging, I rely on CPack variables CPACK_INSTALLED_DIRECTORIES and CPACK_INSTALL_COMMANDS. Unfortunately, packaging is failing in the following conditions: * Platform

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

I completely agree. Seems reasonable to disallow exporting ALIAS targets. Marc On 14/09/15 19:34, "cmake-developers on behalf of Stephen Kelly" wrote: >Michael Scott wrote: > >> Hi, >> >> I'm planning on having a look at

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Hi Michael, If this feature can be supported for libraries and executables, it will be perfect for me. Thank you. Marc On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" wrote: >Hi, > >I'm planning

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

Any news on this subject? I think it is a critical bug because behaviour is broken. So I cannot rely on find_executable anymore to get the expected program! Marc On 09/09/15 20:20, "Brad King" wrote: >On 09/09/2015 11:50 AM, Chuck Atkins wrote: >> From what I can

Re: [cmake-developers] CXX_STANDARD and linking

On Solaris, activating C++11 standard switch the compiler into a completely different mode: * Mangling is different * C++ runtime is the GNU one, delivered as part of SolarisStudio 12.4 (Sun C++ runtime is no longer supported) This is why the flag -std=c++11 must be passed to the link step to

Re: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4)

to fix this problem anytime soon? After this problem fixed, I hope CMake bootstrapping will be solved as well… Thank you for your help. Marc On 25/09/15 17:24, "Brad King" <brad.k...@kitware.com> wrote: >Steve, > >On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote: >&g

Re: [cmake-developers] CXX_STANDARD and linking

Seems OK for me… But my personal situation is even worst now! :) The situation evolved from a buggy support of C++11 on Solaris to no support at all. Do you have any idea (and schedule) for re-introduction of this feature, knowing that the key point is the lack of propagating of c++11 compile

[cmake-developers] [CMake][BUG] C++11 support broken for SolarisStudio 12.4

Hi, Currently, it is not possible to use C++11 mode on Solaris with SolarisStudio 12.4 (test done on Solaris 11.2 sparc). If I try a simple executable (see attached file), compilation is OK (option –std=c++11 is correctly passed to compiler) but link failed because, with SolarisStudio

[cmake-developers] [CMake][BUG] Unable to build CMake with SolarisStudio 12.4

Hi, Attached is a patch fixing compilation error which prevent building CMake with SolarisStudio 12.4. Marc 0001-SolarisStudio-12.4-cmake-compilation-fix.patch Description: 0001-SolarisStudio-12.4-cmake-compilation-fix.patch -- Powered by www.kitware.com Please keep messages on-topic and

Re: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

Hi Domen, Good news! With your patch, packaging on Windows is now working as expected. Thank you. Marc On 25/09/15 10:34, "Domen Vrankar" <domen.vran...@gmail.com> wrote: >2015-09-24 9:06 GMT+02:00 Domen Vrankar <domen.vran...@gmail.com>: >> 2015-09-23

[cmake-developers] [CMake][BUG] Ensure C based tests do not used C++ syntax

Hi, I encountered some problems validating a CMake build on AIX using IBM xlc/xlC compilers. The problem comes from the fact that, by default, C compiler does not recognized C++-Style comments. So, attached is a patch ensuring that sources compiling with a C compiler have C-Style comments

[cmake-developers] [CMake][BUG] ProcessorCount is broken on current SunOS systems

Hi, Attached is a patch to ensure that ProcessorCount returns correct information on recent SunOS systems (tested on Sunos 5.11 (i.e. Solaris 11.2)). Marc 0001-Update-ProcessorCount-module-for-recent-SunOS.patch Description: 0001-Update-ProcessorCount-module-for-recent-SunOS.patch --

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

Oops ! You are right, on a simple example, all is OK. So the problem seems on my side. I will investigate this curious behaviour… Sorry for the noise. Marc On 09/12/15 15:15, "Brad King" <brad.k...@kitware.com> wrote: >On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

. Marc On 09/12/15 15:00, "Brad King" <brad.k...@kitware.com> wrote: >On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote: >> Attached is a patch for AIX enabling correct generation of executables >> regarding runtime path handling (currently, build paths could be

[cmake-developers] [CMake][PATCH] Fix support of policy 0065 on AIX

Hi, Attached is a patch to handle correctly policy 0065 and avoid lost of some required link flags (I.e. -bnoipath) Marc 0001-Fix-support-of-policy-0065-on-AIX.patch Description: 0001-Fix-support-of-policy-0065-on-AIX.patch -- Powered by www.kitware.com Please keep messages on-topic and

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

and Linux). Marc On 09/12/15 15:41, "cmake-developers on behalf of CHEVRIER, Marc" <cmake-developers-boun...@cmake.org on behalf of marc.chevr...@sap.com> wrote: > >Oops ! >You are right, on a simple example, all is OK. So the problem seems on my side. >I will invest

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

Ok. I see the problem. Thanks for your investigation. I will work on that and submit a patch to solve this problem. Marc On 10/12/15 14:42, "Brad King" <brad.k...@kitware.com> wrote: >On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote: >> I identify the root of the prob

[cmake-developers] [CMAKE][PATCH] fix create_javah on Windows

Hi, Attached is a patch fixing erroneous handling of CLASSPATH parameter for function create_javah (module UseJava). Update tests accordingly. Marc 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch Description: 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch -- Powered

[cmake-developers] Support of Scala language

Hi, I have just started to work to extend CMake to support Scala language. This language is very similar to Java regarding compilation (scala compiler generates .class (java byte code)) and packaging (binary files can be packaged in jar files) and is running as part of JVM infrastructure.

Re: [cmake-developers] Support of Scala language

in CMake: * All sources composing a jar must be compiled all at once * A source file can produce an arbitrary number of binary files (.class) with various (and unpredictable) names. Marc On 18/02/16 16:06, "Brad King" <brad.k...@kitware.com> wrote: >On 02/18/2016 06:28 AM, C

[cmake-developers] CTest Usage

Hi, Is there someone able to help me regarding ctest usage with labels? Here is the problem: I have various tests which have labels attached to them: set_property (TEST test1 PROPERTY LABELS LABEL1) set_property (TEST test2 PROPERTY LABELS LABEL1 LABEL2) set_property (TEST test3 PROPERTY LABELS

Re: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES

A more generic approach for cleanup actions is to add a new property which enables to specify a cmake script. And, in the script, everyone is free to do what he wants… Example: set_directory_properties (PROPERTIES ADDITIONAL_MAKE_CLEAN_SCRIPT "my_clean_script.cmake") From: cmake-developers

Re: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct?

Yes, the "cmake_policy" command is here on purpose because the "new" module rely on features (mainly source properties) introduced in CMake version 3.11. On 04/04/2018 21:18, "cmake-developers on behalf of Alan W. Irwin"