date:20170518

[CMake] cmake to download and compile fftw library

2017-05-18 Thread aishwarya selvaraj

Hi all,
I have written the below cmakelist.txt .



CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(PROSE)


include(ExternalProject)
MESSAGE(STATUS "Trying to install fftw...")

ExternalProject_Add(project_fftw
  #GIT_REPOSITORY  https://github.com/FFTW/fftw3
  URL "http://www.fftw.org/fftw-3.3.2.tar.gz;
  PREFIX ${CMAKE_CURRENT_BINARY_DIR}/fftw
  CONFIGURE_COMMAND ""
#--Build step-
  BUILD_COMMAND ""
#--Install step---
  UPDATE_COMMAND "" # Skip annoying updates for every build
  INSTALL_COMMAND ""
 )

ADD_LIBRARY(fftw INTERFACE)


TARGET_INCLUDE_DIRECTORIES(fftw INTERFACE
"${install_dir}/src/project_fftw/api/")


ADD_EXECUTABLE(prose ${PROJECT_SOURCE_DIR}/src/read.cpp)
TARGET_LINK_LIBRARIES(prose fftw  )



But when I run it in cygwin (windows) I get the following error:
*Scanning dependencies of target prose*
*[ 94%] Building CXX object CMakeFiles/prose.dir/src/read.cpp.o*
*/home/computing7/prose/src/read.cpp:17:19: fatal error: fftw3.h: No such
file or directory*
*compilation terminated.*
*make[2]: *** [CMakeFiles/prose.dir/build.make:63:
CMakeFiles/prose.dir/src/read.
 cpp.o] Error 1*
*make[1]: *** [CMakeFiles/Makefile2:142: CMakeFiles/prose.dir/all] Error 2*
*make: *** [Makefile:84: all] Error 2*

Could anyone please tell me on how to solve this problem .

-- 
Regards,
Aishwarya Selvaraj
-- 

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-commits] CMake branch, master, updated. v3.8.1-1232-gde41f3b

2017-05-18 Thread Kitware Robot

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  de41f3b38c0d5e8d7045cd5e6e96eef72c388d5b (commit)
  from  bc7d64f896d6e180970cb404cc7699732db34adc (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=de41f3b38c0d5e8d7045cd5e6e96eef72c388d5b
commit de41f3b38c0d5e8d7045cd5e6e96eef72c388d5b
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri May 19 00:01:06 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri May 19 00:01:06 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2ac81fa..5cb5a84 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 8)
-set(CMake_VERSION_PATCH 20170518)
+set(CMake_VERSION_PATCH 20170519)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] Compile targets affected by changeset

2017-05-18 Thread Robert Patterson via cmake-developers

Greetings,My company has a large, predominately C++ codebase, with hundreds of targets, both for product and unit tests.  In an effort to improve the compile and test time for developers, which utilizes a continuous integration infrastructure, it is desirable to compile only the targets that are affected by developer's change sets.Our approach leverages the cmake target source file information, along with the dependency graph, to identify which targets are directly affected by the changeset, and then trace the dependency graph to find all targets which depend on these files. We use 'make', so cmake does not analyze header information, so we must have a preprocessing step (makedepend or gcc -M) to identify which source files may be affected by the header files in the change set. These indirectly changed sources are fed back into the file changeset.'make' has a limitation where if 'make target1 target2 target3' is invoked, target1, target2, and target3 are built serially, not in parallel. To get around this, we decided that the best option was to dynamically create a new [cmake] target which depends on the affected targets. This is where we could use some guidance as we have two possible approaches: 1. This could either be implemented in cmake code; by supplying a command line argument, specifying the "dynamic" target which in turn would create a target during the generation process. 2. Explicitly specify the "dynamic" target in our project's CMakeLists.txt file, and allow cmake to simply add the affected targets as a dependency to the dynamic target.Our current (attached) patch adds an option (--change-set=) for to cmake to read a (newline separated with absolute paths) file which contains the list of files in the changeset. cmake parses the file and outputs the set of affected targets and then exits before makefile generation.We would like your opinions on how to best implement this. Would it be better to handle the creation of the dummy target in CMakeLists.txt, or to handle it in cmake code?  Additionally, would you be interested in adopting these changes upstream?option 1:cmake --change-set=mychanges.txt >> targets.txtcreate dummy target in CMakeLists.txtcmake (parses targets.txt and adds dependencies to dummy-target)make dummy-target pros: simple, small addition to cmakecons: less general, complexity moved to build scriptsoption 2:cmake --change-set=mychanges.txt >> targets.txtcmake --dependencies=targets.txt --dynamic-target=dummy-targetmake dummy-targetoption 3:cmake --change-set=mychanges.txt --dynamic-target=dummy-targetmake dummy-targetpros: more generalcons: more complexity introduced to cmake codeI appreciate your time and look forward to your feedback.--Robert Patterson

compile-changeset.patch
Description: Binary data
-- 

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] Force target to always run last?

2017-05-18 Thread Patrick Boettcher

Now that you described in more detail what you're trying to do I
realized that I had a similar problem to solve.

It's about generating packages for an arm-based linux-build
(Yocto-based). I decided against integrating my build into the
Yocto-build and instead I'm using cmake to cross-compile the
executables and libraries (C and C++).

Packaging is done with an IPK-file via a script launched by cmake
as the last step of the build process.

For each library and executable which belongs to a future ipk-package
I'm adding an install()-command which will, when the install-target
is run, place the files into a directory inside the build dir. This
directory is a dedicated one for the package:

For example:

top-level:

  set(PACKAGE_DIR ${CMAKE_BINARY_DIR}/common-exe-package)

Somewhere in the hierarchy of the project's CMakeLists.txt

  add_library(common src.cpp [..])
  install(TARGETS common
  DESTINATION ${PACKAGE_DIR}/usr/lib)

and again somewhere else

  add_executable(exe exe.cpp)
  target_link_libraries(exe PRIVATE common)
  install(TARGETS exe
  DESTINATION ${PACKAGE_DIR}/usr/bin)

Then I create a custom_target to create the package:

  add_custom_target(
ipk-common-exe
COMMAND
[..] # commands to finalize the ipk-tree and
 # tar xfz ... to make the ipk-files
COMMENT "creating common-exe IPK"
WORKING_DIRECTORY
${PACKAGE_DIR}
  )
  
  # add dependencies to a install-and-strip-target
  add_dependencies(ipk-common-exe install-and-strip)

The "install-and-strip"-target is defined at the top-level

  add_custom_target(
  install-and-strip
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} 
  --target install/strip)

the built-in install/strip-target has a dependency to all
targets use with install(TARGET ...) 

I'm using ninja and make -jX, both work in parallel. I'm build several
packages in one cmake-build. Works like a charm.

An additional bonus is that the install-target also removed RPATHs from
executables. 

HTH,
--
Patrick.




On Thu, 18 May 2017 11:16:47 -0500
Robert Dailey  wrote:

> So let me go over the problem I'm trying to solve, because it's
> possible at this point I'm over-engineering it, but it's hard to fix.
> 
> So my build process is for native shared library targets that
> eventually get included in an APK for Android. I'm using the NDK
> toolchain to build my native targets. The general flow from nothing to
> complete APK is as follows:
> 
> 1. Build all native library targets
> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
> in the android project directory (where the src, res, and other
> android directories are located)
> 3. Run custom commands that basically invoke 'ant release', and since
> I positioned the *.so files under 'libs' they get packaged with the
> APK itself.
> 
> This is how I provide support for using CMake to build native, run
> java build, and perform APK packaging.
> 
> There's a lot of setup that happens in CMake in order to make sure the
> 'ant release' command behaves as expected. I have to handle a few
> corner cases:
> 
> * Each new build of the custom target that runs the 'ant release'
> command has to only contain the *.so files that were built during that
> run
> * Various third-party libraries (pre-compiled *.so files) have to also
> be copied to libs/armeabi-v7a for only certain android projects,
> because we do not want duplicated *.so files across multiple android
> libraries (ant release will fail if there are duplicate *.so files
> across android project dependencies)
> 
> So given this, my complete pipeline is as follows:
> 
> 1. A `android_clean_libs` custom target is run which iterates all
> known native targets with mapped java projects and completely deletes
> its 'libs' directory (this is a forced clean prior to building)
> 2. A `copy_dlls` target runs next, which copies third party
> (precompiled) *.so files to a single common java project, in its
> 'libs/armeabi-v7a' directory.
> 3. Each native target now builds in parallel, as a post-build event it
> copies its output *.so file to its respective libs/armeabi-v7a
> directory for packaging.
> 4. A final 'package' custom target runs which runs 'ant release' on
> the bottom-most android project (that is not a library target by
> itself).
> 
> The part I don't like here is step #1. I don't like the clean to
> require keeping track of a global property of a list of directories to
> remove. Ideally, #1 should run as a post-build event during step 3.
> Basically each native target should delete its 'libs' directory prior
> to copying its own *.so target to that directory. However, I can't do
> this because of step #2. Step 2 must happen first, because it's the
> only way I can guarantee that it will execute regardless of which
> target I build (all, or specific target). I make `copy_dlls` a
> dependency of every other target, so it always runs. If I could force
> it

Re: [CMake] Force target to always run last?

2017-05-18 Thread David Cole via CMake

Hopefully, somebody else doing something similar to what you're doing
will chime in here.

Seems overly complicated from an outsider's perspective.

If what you say is true ...:
"If 'copy_dlls' happens while 'B' is building, then it's possible the
post-build event run by B that deletes the 'libs' directory also
deletes some files copied by 'copy_dlls'"

...then copy_dlls depends on B, because if it runs before or while B
is running, you have problems. So it has to run after.

Seems like you have some untangling to do.



On Thu, May 18, 2017 at 3:42 PM, Robert Dailey  wrote:
> To be clear, I do have a "package" target per real native target.
> However, if I set up the dependencies like so:
>
> Target 'A' depends on 'copy_dlls'
> Target 'A' depends on target 'B'
> Target 'A_package' depends on 'A'
> Target 'A_package' depends on 'copy_dlls'
>
> Furthermore, the add_custom_command() to delete 'libs' and copy the
> *.so is added to 'A' and 'B' (each for their own 'libs' directory and
> their own *.so output)
>
> Then when I do:
>
> $ ninja A_package
>
> The following items are built in any order (due to parallel builds):
>
> * B
> * A (after B)
> * copy_dlls
>
> If 'copy_dlls' happens while 'B' is building, then it's possible the
> post-build event run by B that deletes the 'libs' directory also
> deletes some files copied by 'copy_dlls', which means those files will
> not get packaged when 'A_package' invokes `ant release` for the APK
> packaging.
>
> I hope that makes the issue a little clearer... sorry for the confusion.
>
> On Thu, May 18, 2017 at 1:22 PM, David Cole  wrote:
>> Seems to me the simplest thing to do would be to have copy_dlls depend
>> on nothing, and have package depend on copy_dlls and all the native
>> targets, and then tell your developers to run:
>>
>>   make individualTarget && make package
>>
>> Either that, or introduce a packageIndividualTarget target for each
>> individualTarget.
>>
>> Maybe I just don't understand fully, but why would you ever "make
>> individualTarget" and then expect package to work properly? What if
>> stuff that depends on that individualTarget also needs to rebuild
>> before packaging? Shouldn't you have to do a build all to guarantee
>> that packaging the results works properly?
>>
>>
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
>>  wrote:
>>> So let me go over the problem I'm trying to solve, because it's
>>> possible at this point I'm over-engineering it, but it's hard to fix.
>>>
>>> So my build process is for native shared library targets that
>>> eventually get included in an APK for Android. I'm using the NDK
>>> toolchain to build my native targets. The general flow from nothing to
>>> complete APK is as follows:
>>>
>>> 1. Build all native library targets
>>> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
>>> in the android project directory (where the src, res, and other
>>> android directories are located)
>>> 3. Run custom commands that basically invoke 'ant release', and since
>>> I positioned the *.so files under 'libs' they get packaged with the
>>> APK itself.
>>>
>>> This is how I provide support for using CMake to build native, run
>>> java build, and perform APK packaging.
>>>
>>> There's a lot of setup that happens in CMake in order to make sure the
>>> 'ant release' command behaves as expected. I have to handle a few
>>> corner cases:
>>>
>>> * Each new build of the custom target that runs the 'ant release'
>>> command has to only contain the *.so files that were built during that
>>> run
>>> * Various third-party libraries (pre-compiled *.so files) have to also
>>> be copied to libs/armeabi-v7a for only certain android projects,
>>> because we do not want duplicated *.so files across multiple android
>>> libraries (ant release will fail if there are duplicate *.so files
>>> across android project dependencies)
>>>
>>> So given this, my complete pipeline is as follows:
>>>
>>> 1. A `android_clean_libs` custom target is run which iterates all
>>> known native targets with mapped java projects and completely deletes
>>> its 'libs' directory (this is a forced clean prior to building)
>>> 2. A `copy_dlls` target runs next, which copies third party
>>> (precompiled) *.so files to a single common java project, in its
>>> 'libs/armeabi-v7a' directory.
>>> 3. Each native target now builds in parallel, as a post-build event it
>>> copies its output *.so file to its respective libs/armeabi-v7a
>>> directory for packaging.
>>> 4. A final 'package' custom target runs which runs 'ant release' on
>>> the bottom-most android project (that is not a library target by
>>> itself).
>>>
>>> The part I don't like here is step #1. I don't like the clean to
>>> require keeping track of a global property of a list of directories to
>>> remove. Ideally, #1 should run as a post-build event during step 3.
>>> Basically each native target should delete

[cmake-developers] Making your regular expression engine more reliable

2017-05-18 Thread Alan W. Irwin


I have just discovered a long-standing regular expression bug (see
) that has been
around since at least 3.0.2.

So your unit tests for regular expressions obviously missed at least
this issue. I have no idea what those unit tests are (or even if they
exist), but one possibility for attempting to wring most of the bugs out
of your regular expression processor is to adapt some other project's
regexp test suite. See

for a rather large list of such test suites.

Another possibility is simply to forget supporting your own regexp
engine and adopt someone else's very well regarded regexp engine (such
as libprng).  I vaguely recall that has been suggested before, but
since that hasn't happened I presume inertia or NIH syndrome won or
else there was some strong reason why you didn't go that route.


From my perspective as a strongly interested CMake user (but not a

CMake developer or regexp guru) that wants a completely reliable
regular expression engine for CMake, I don't care which of these two
approaches you use to achieve that goal.  But I hope my starting
this topic here will facilitate reaching that goal.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Force target to always run last?

2017-05-18 Thread Robert Dailey

To be clear, I do have a "package" target per real native target.
However, if I set up the dependencies like so:

Target 'A' depends on 'copy_dlls'
Target 'A' depends on target 'B'
Target 'A_package' depends on 'A'
Target 'A_package' depends on 'copy_dlls'

Furthermore, the add_custom_command() to delete 'libs' and copy the
*.so is added to 'A' and 'B' (each for their own 'libs' directory and
their own *.so output)

Then when I do:

$ ninja A_package

The following items are built in any order (due to parallel builds):

* B
* A (after B)
* copy_dlls

If 'copy_dlls' happens while 'B' is building, then it's possible the
post-build event run by B that deletes the 'libs' directory also
deletes some files copied by 'copy_dlls', which means those files will
not get packaged when 'A_package' invokes `ant release` for the APK
packaging.

I hope that makes the issue a little clearer... sorry for the confusion.

On Thu, May 18, 2017 at 1:22 PM, David Cole  wrote:
> Seems to me the simplest thing to do would be to have copy_dlls depend
> on nothing, and have package depend on copy_dlls and all the native
> targets, and then tell your developers to run:
>
>   make individualTarget && make package
>
> Either that, or introduce a packageIndividualTarget target for each
> individualTarget.
>
> Maybe I just don't understand fully, but why would you ever "make
> individualTarget" and then expect package to work properly? What if
> stuff that depends on that individualTarget also needs to rebuild
> before packaging? Shouldn't you have to do a build all to guarantee
> that packaging the results works properly?
>
>
>
>
>
>
> On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
>  wrote:
>> So let me go over the problem I'm trying to solve, because it's
>> possible at this point I'm over-engineering it, but it's hard to fix.
>>
>> So my build process is for native shared library targets that
>> eventually get included in an APK for Android. I'm using the NDK
>> toolchain to build my native targets. The general flow from nothing to
>> complete APK is as follows:
>>
>> 1. Build all native library targets
>> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
>> in the android project directory (where the src, res, and other
>> android directories are located)
>> 3. Run custom commands that basically invoke 'ant release', and since
>> I positioned the *.so files under 'libs' they get packaged with the
>> APK itself.
>>
>> This is how I provide support for using CMake to build native, run
>> java build, and perform APK packaging.
>>
>> There's a lot of setup that happens in CMake in order to make sure the
>> 'ant release' command behaves as expected. I have to handle a few
>> corner cases:
>>
>> * Each new build of the custom target that runs the 'ant release'
>> command has to only contain the *.so files that were built during that
>> run
>> * Various third-party libraries (pre-compiled *.so files) have to also
>> be copied to libs/armeabi-v7a for only certain android projects,
>> because we do not want duplicated *.so files across multiple android
>> libraries (ant release will fail if there are duplicate *.so files
>> across android project dependencies)
>>
>> So given this, my complete pipeline is as follows:
>>
>> 1. A `android_clean_libs` custom target is run which iterates all
>> known native targets with mapped java projects and completely deletes
>> its 'libs' directory (this is a forced clean prior to building)
>> 2. A `copy_dlls` target runs next, which copies third party
>> (precompiled) *.so files to a single common java project, in its
>> 'libs/armeabi-v7a' directory.
>> 3. Each native target now builds in parallel, as a post-build event it
>> copies its output *.so file to its respective libs/armeabi-v7a
>> directory for packaging.
>> 4. A final 'package' custom target runs which runs 'ant release' on
>> the bottom-most android project (that is not a library target by
>> itself).
>>
>> The part I don't like here is step #1. I don't like the clean to
>> require keeping track of a global property of a list of directories to
>> remove. Ideally, #1 should run as a post-build event during step 3.
>> Basically each native target should delete its 'libs' directory prior
>> to copying its own *.so target to that directory. However, I can't do
>> this because of step #2. Step 2 must happen first, because it's the
>> only way I can guarantee that it will execute regardless of which
>> target I build (all, or specific target). I make `copy_dlls` a
>> dependency of every other target, so it always runs. If I could force
>> it to run *last*, then I could simplify step 1.
>>
>> Sorry if this is too much information or if I've not explained things
>> clearly, but I wanted to hash out the details because maybe there is a
>> better approach. I'm willing to start from scratch on this if it
>> improves the design of the targets.
>>
>> Thanks again!!
>>
>>
>> On Thu, May 18,

Re: [CMake] Force target to always run last?

2017-05-18 Thread David Cole via CMake

Seems to me the simplest thing to do would be to have copy_dlls depend
on nothing, and have package depend on copy_dlls and all the native
targets, and then tell your developers to run:

  make individualTarget && make package

Either that, or introduce a packageIndividualTarget target for each
individualTarget.

Maybe I just don't understand fully, but why would you ever "make
individualTarget" and then expect package to work properly? What if
stuff that depends on that individualTarget also needs to rebuild
before packaging? Shouldn't you have to do a build all to guarantee
that packaging the results works properly?






On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
 wrote:
> So let me go over the problem I'm trying to solve, because it's
> possible at this point I'm over-engineering it, but it's hard to fix.
>
> So my build process is for native shared library targets that
> eventually get included in an APK for Android. I'm using the NDK
> toolchain to build my native targets. The general flow from nothing to
> complete APK is as follows:
>
> 1. Build all native library targets
> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
> in the android project directory (where the src, res, and other
> android directories are located)
> 3. Run custom commands that basically invoke 'ant release', and since
> I positioned the *.so files under 'libs' they get packaged with the
> APK itself.
>
> This is how I provide support for using CMake to build native, run
> java build, and perform APK packaging.
>
> There's a lot of setup that happens in CMake in order to make sure the
> 'ant release' command behaves as expected. I have to handle a few
> corner cases:
>
> * Each new build of the custom target that runs the 'ant release'
> command has to only contain the *.so files that were built during that
> run
> * Various third-party libraries (pre-compiled *.so files) have to also
> be copied to libs/armeabi-v7a for only certain android projects,
> because we do not want duplicated *.so files across multiple android
> libraries (ant release will fail if there are duplicate *.so files
> across android project dependencies)
>
> So given this, my complete pipeline is as follows:
>
> 1. A `android_clean_libs` custom target is run which iterates all
> known native targets with mapped java projects and completely deletes
> its 'libs' directory (this is a forced clean prior to building)
> 2. A `copy_dlls` target runs next, which copies third party
> (precompiled) *.so files to a single common java project, in its
> 'libs/armeabi-v7a' directory.
> 3. Each native target now builds in parallel, as a post-build event it
> copies its output *.so file to its respective libs/armeabi-v7a
> directory for packaging.
> 4. A final 'package' custom target runs which runs 'ant release' on
> the bottom-most android project (that is not a library target by
> itself).
>
> The part I don't like here is step #1. I don't like the clean to
> require keeping track of a global property of a list of directories to
> remove. Ideally, #1 should run as a post-build event during step 3.
> Basically each native target should delete its 'libs' directory prior
> to copying its own *.so target to that directory. However, I can't do
> this because of step #2. Step 2 must happen first, because it's the
> only way I can guarantee that it will execute regardless of which
> target I build (all, or specific target). I make `copy_dlls` a
> dependency of every other target, so it always runs. If I could force
> it to run *last*, then I could simplify step 1.
>
> Sorry if this is too much information or if I've not explained things
> clearly, but I wanted to hash out the details because maybe there is a
> better approach. I'm willing to start from scratch on this if it
> improves the design of the targets.
>
> Thanks again!!
>
>
> On Thu, May 18, 2017 at 10:51 AM, David Cole  wrote:
>> I'm sorry, I misunderstood that you wanted it to run last regardless
>> of what target you are building. I was assuming you wanted it to
>> happen when you build the "all" target. I didn't think you wanted to
>> run it after any other *individual* target which you might specify.
>>
>> I don't know of an easy way to do that. You could add a custom command
>> as a post-build command on every single target, but that seems like it
>> wouldn't work for you either, as it would run the command potentially
>> multiple times, with no way to tell whether you're being called last
>> or not.
>>
>> Sorry.
>>
>> Why does this need to run after the build of any individual target?
>> Why not just say there are two ways to get it to run: build "all" or
>> explicitly build it after you build the other individual thing you
>> want?
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 10:24 AM, Robert Dailey
>>  wrote:
>>> David,
>>>
>>> Thanks for your help. So if I do it as you suggest, this will also
>>> require I specify

Re: [CMake] RPATH for external library

2017-05-18 Thread Pawel Veselov

>> > If I understand things correctly, pkg-config does not return the
>> > RPATH-arguments necessary to link with. IOW, if used in a GNU
>> > Makefile you would also need to add these by yourself, right? So
>> > your problem is not a cmake-problem.
>> IMHO it's not fair to say - if it's not supported by GNUmake, it
>> shouldn't be supported by CMake.
> That was not my intention to say. But rather I thought that somewhere
> this problem was already solved, as it is not a cmake-only-problem, but
> a general build problem when using pkg-config on libraries which are not
> in default search-pathes.

Agree.

>> In any case, the CMake documentation says that
>> INSTALL_RPATH_USE_LINK_PATH "...will append directories in the linker
>> search path and outside the project to the INSTALL_RPATH...", there
>> is no statement that it only applies to linker search paths that were
>> supplied in a certain way.
> That applies only to libraries, not the linker-flags which have
> been added behind the back of cmake's library-dependency mechanism.

Right, so it's not all search paths. I would advocate for changing the
documentation so it is clear.

>> [skipped]
> This skipped part was trying to point out a solution based on the -l
> and -L arguments returned by pkg-config and some cmake parsing. It
> wouldn't be beautiful, but it'll work.

Agree. I just didn't have any other comment for that.
-- 

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] FW: CTest question

2017-05-18 Thread Eric Noulard

Hi,

I don't that 2 execute_process in sequence in a cmake script could be
executed out-of-order but I let CMake developer answer more firmly about
that.
The order of each test created by add_test may vary though.

2017-05-18 19:32 GMT+02:00 T.Sariyski :

> Hi Eric,
>
>
>
> I noticed something that may relates to the problem. Like I said in my
> previous mail, add_test is a call to cmake:
>
>
>
> ADD_TEST(NAME ${TARGET_NAME}
>
>…
>
>COMMAND ${CMAKE_COMMAND}
>
> -DPROGRAM1
>
> -DPROGRAM2
>
> …
>
>
>
> Is there a chance that PROGRAM1 and PROGRAM2 are executed asynchronically?
> Here is what I noticed. If a test is executed from its own binary
> directory, ‘ctest -VV’, it always pass. If the same test is executed from
> the main binary directory, ‘ctest -VV -R zamod’,  it fails because PROGRAM2
> is executed before PROGRAM1 is finished. Attached are the screen outputs
> for both runs.
>
>
>
> Thanks,
>
> Ted
>
>
>
>
>
> 
>
> cd CTEST/zamod
>
> s1002807:zamod tesari$ ctest -VV
>
> UpdateCTestConfiguration  from :/Users/tesari/build/gnu.dbg/
> CTEST/zamod/DartConfiguration.tcl
>
> UpdateCTestConfiguration  from :/Users/tesari/build/gnu.dbg/
> CTEST/zamod/DartConfiguration.tcl
>
> Test project /Users/tesari/build/gnu.dbg/CTEST/zamod
>
> Constructing a list of tests
>
> Done constructing a list of tests
>
> Updating test list for fixtures
>
> Added 0 tests to meet fixture requirements
>
> Checking test dependency graph...
>
> Checking test dependency graph end
>
> test 1
>
> Start 1: zamod_serial
>
>
>
> 1: Test command: /Applications/CMake.app/Contents/bin/cmake "-D"
> "PRE_DELETE_OUTPUT_FILES:BOOL=true" "-D" 
> "OUTPUT_FILES:STRING=*kdk*;*.exo;*.jpg;*.png;*.log;*~"
> "-D" "PROGRAM1:STRING=/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod
> &&  /Users/tesari/build/gnu.dbg/bin/kodiak zamod" "-D"
> "PROGRAM2:STRING=python;/Users/tesari/kodiak/trunk/
> benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.
> dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
> "-P" "run_and_assert.cmake"
>
> 1: Test timeout computed to be: 9.99988e+06
>
> 1: -- Executing "/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod
> &&  /Users/tesari/build/gnu.dbg/bin/kodiak zamod"
>
> 1: -- Executing "python;/Users/tesari/kodiak/trunk/benchmark/Scripts/
> assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/
> hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
>
> 1: /Users/tesari/kodiak/trunk/benchmark/Scripts
>
> 1: Number of arguments: 4 arguments.
>
> 1: Argument List: ['/Users/tesari/kodiak/trunk/
> benchmark/Scripts/assert_case.py', 
> '/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk',
> '/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk', '0']
>
> 1: /Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py called
> with  3  arguments:
>
> 1: 1 /Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk
>
> 1: 2 /Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk
>
> 1: 3 0
>
> 1:zamod Q0.4 PASS
>
> 1:zamod Q0.5 PASS
>
> 1: Kodiak ctest: SUCCESS
>
> 1/1 Test #1: zamod_serial .   Passed5.73 sec
>
>
>
>
>
> 
>
> s1002807:gnu.dbg tesari$ ctest -VV -R zamod
>
> UpdateCTestConfiguration  from :/Users/tesari/build/gnu.dbg/
> DartConfiguration.tcl
>
> Parse Config file:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl
>
> UpdateCTestConfiguration  from :/Users/tesari/build/gnu.dbg/
> DartConfiguration.tcl
>
> Parse Config file:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl
>
> Test project /Users/tesari/build/gnu.dbg
>
> Constructing a list of tests
>
> Done constructing a list of tests
>
> Updating test list for fixtures
>
> Added 0 tests to meet fixture requirements
>
> Checking test dependency graph...
>
> Checking test dependency graph end
>
> test 113
>
> Start 113: zamod_serial
>
>
>
> 113: Test command: /Applications/CMake.app/Contents/bin/cmake "-D"
> "PRE_DELETE_OUTPUT_FILES:BOOL=true" "-D" 
> "OUTPUT_FILES:STRING=*kdk*;*.exo;*.jpg;*.png;*.log;*~"
> "-D" "PROGRAM1:STRING=/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod
> &&  /Users/tesari/build/gnu.dbg/bin/kodiak zamod" "-D"
> "PROGRAM2:STRING=python;/Users/tesari/kodiak/trunk/
> benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.
> dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
> "-P" "run_and_assert.cmake"
>
> 113: Test timeout computed to be: 1500
>
> 113: -- Executing "/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod
> &&  /Users/tesari/build/gnu.dbg/bin/kodiak zamod"
>
> 113: -- Executing "python;/Users/tesari/kodiak/trunk/benchmark/Scripts/
> assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/
> hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
>
> 113:

[CMake] FW: CTest question

2017-05-18 Thread T.Sariyski

Hi Eric, 

 

I noticed something that may relates to the problem. Like I said in my previous 
mail, add_test is a call to cmake:

 

ADD_TEST(NAME ${TARGET_NAME}

   …

   COMMAND ${CMAKE_COMMAND} 

-DPROGRAM1 

-DPROGRAM2  

…

 

Is there a chance that PROGRAM1 and PROGRAM2 are executed asynchronically? Here 
is what I noticed. If a test is executed from its own binary directory, ‘ctest 
-VV’, it always pass. If the same test is executed from the main binary 
directory, ‘ctest -VV -R zamod’,  it fails because PROGRAM2 is executed before 
PROGRAM1 is finished. Attached are the screen outputs for both runs. 

 

Thanks,

Ted

 

 



cd CTEST/zamod

s1002807:zamod tesari$ ctest -VV

UpdateCTestConfiguration  from 
:/Users/tesari/build/gnu.dbg/CTEST/zamod/DartConfiguration.tcl

UpdateCTestConfiguration  from 
:/Users/tesari/build/gnu.dbg/CTEST/zamod/DartConfiguration.tcl

Test project /Users/tesari/build/gnu.dbg/CTEST/zamod

Constructing a list of tests

Done constructing a list of tests

Updating test list for fixtures

Added 0 tests to meet fixture requirements

Checking test dependency graph...

Checking test dependency graph end

test 1

Start 1: zamod_serial

 

1: Test command: /Applications/CMake.app/Contents/bin/cmake "-D" 
"PRE_DELETE_OUTPUT_FILES:BOOL=true" "-D" 
"OUTPUT_FILES:STRING=*kdk*;*.exo;*.jpg;*.png;*.log;*~" "-D" 
"PROGRAM1:STRING=/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod &&  
/Users/tesari/build/gnu.dbg/bin/kodiak zamod" "-D" 
"PROGRAM2:STRING=python;/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
 "-P" "run_and_assert.cmake"

1: Test timeout computed to be: 9.99988e+06

1: -- Executing "/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod &&  
/Users/tesari/build/gnu.dbg/bin/kodiak zamod"

1: -- Executing 
"python;/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"

1: /Users/tesari/kodiak/trunk/benchmark/Scripts

1: Number of arguments: 4 arguments.

1: Argument List: 
['/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py', 
'/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk', 
'/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk', '0']

1: /Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py called with  3  
arguments:

1: 1 /Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk

1: 2 /Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk

1: 3 0

1:zamod Q0.4 PASS

1:zamod Q0.5 PASS

1: Kodiak ctest: SUCCESS

1/1 Test #1: zamod_serial .   Passed5.73 sec

 

 



s1002807:gnu.dbg tesari$ ctest -VV -R zamod

UpdateCTestConfiguration  from 
:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl

Parse Config file:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl

UpdateCTestConfiguration  from 
:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl

Parse Config file:/Users/tesari/build/gnu.dbg/DartConfiguration.tcl

Test project /Users/tesari/build/gnu.dbg

Constructing a list of tests

Done constructing a list of tests

Updating test list for fixtures

Added 0 tests to meet fixture requirements

Checking test dependency graph...

Checking test dependency graph end

test 113

Start 113: zamod_serial

 

113: Test command: /Applications/CMake.app/Contents/bin/cmake "-D" 
"PRE_DELETE_OUTPUT_FILES:BOOL=true" "-D" 
"OUTPUT_FILES:STRING=*kdk*;*.exo;*.jpg;*.png;*.log;*~" "-D" 
"PROGRAM1:STRING=/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod &&  
/Users/tesari/build/gnu.dbg/bin/kodiak zamod" "-D" 
"PROGRAM2:STRING=python;/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"
 "-P" "run_and_assert.cmake"

113: Test timeout computed to be: 1500

113: -- Executing "/bin/sh;-c;cd /Users/tesari/build/gnu.dbg/CTEST/zamod &&  
/Users/tesari/build/gnu.dbg/bin/kodiak zamod"

113: -- Executing 
"python;/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py;/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk;/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk;0"

113: /Users/tesari/kodiak/trunk/benchmark/Scripts

113: Number of arguments: 4 arguments.

113: Argument List: 
['/Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py', 
'/Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk', 
'/Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk', '0']

113: /Users/tesari/kodiak/trunk/benchmark/Scripts/assert_case.py called with  3 
 arguments:

113: 1 /Users/tesari/build/gnu.dbg/CTEST/zamod/hskdk

113: 2 /Users/tesari/kodiak/trunk/CTEST/zamod/../GOLD/zamod/hskdk

113: 3 0

113:

Re: [CMake] Force target to always run last?

2017-05-18 Thread Robert Dailey

So let me go over the problem I'm trying to solve, because it's
possible at this point I'm over-engineering it, but it's hard to fix.

So my build process is for native shared library targets that
eventually get included in an APK for Android. I'm using the NDK
toolchain to build my native targets. The general flow from nothing to
complete APK is as follows:

1. Build all native library targets
2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
in the android project directory (where the src, res, and other
android directories are located)
3. Run custom commands that basically invoke 'ant release', and since
I positioned the *.so files under 'libs' they get packaged with the
APK itself.

This is how I provide support for using CMake to build native, run
java build, and perform APK packaging.

There's a lot of setup that happens in CMake in order to make sure the
'ant release' command behaves as expected. I have to handle a few
corner cases:

* Each new build of the custom target that runs the 'ant release'
command has to only contain the *.so files that were built during that
run
* Various third-party libraries (pre-compiled *.so files) have to also
be copied to libs/armeabi-v7a for only certain android projects,
because we do not want duplicated *.so files across multiple android
libraries (ant release will fail if there are duplicate *.so files
across android project dependencies)

So given this, my complete pipeline is as follows:

1. A `android_clean_libs` custom target is run which iterates all
known native targets with mapped java projects and completely deletes
its 'libs' directory (this is a forced clean prior to building)
2. A `copy_dlls` target runs next, which copies third party
(precompiled) *.so files to a single common java project, in its
'libs/armeabi-v7a' directory.
3. Each native target now builds in parallel, as a post-build event it
copies its output *.so file to its respective libs/armeabi-v7a
directory for packaging.
4. A final 'package' custom target runs which runs 'ant release' on
the bottom-most android project (that is not a library target by
itself).

The part I don't like here is step #1. I don't like the clean to
require keeping track of a global property of a list of directories to
remove. Ideally, #1 should run as a post-build event during step 3.
Basically each native target should delete its 'libs' directory prior
to copying its own *.so target to that directory. However, I can't do
this because of step #2. Step 2 must happen first, because it's the
only way I can guarantee that it will execute regardless of which
target I build (all, or specific target). I make `copy_dlls` a
dependency of every other target, so it always runs. If I could force
it to run *last*, then I could simplify step 1.

Sorry if this is too much information or if I've not explained things
clearly, but I wanted to hash out the details because maybe there is a
better approach. I'm willing to start from scratch on this if it
improves the design of the targets.

Thanks again!!

On Thu, May 18, 2017 at 10:51 AM, David Cole  wrote:
> I'm sorry, I misunderstood that you wanted it to run last regardless
> of what target you are building. I was assuming you wanted it to
> happen when you build the "all" target. I didn't think you wanted to
> run it after any other *individual* target which you might specify.
>
> I don't know of an easy way to do that. You could add a custom command
> as a post-build command on every single target, but that seems like it
> wouldn't work for you either, as it would run the command potentially
> multiple times, with no way to tell whether you're being called last
> or not.
>
> Sorry.
>
> Why does this need to run after the build of any individual target?
> Why not just say there are two ways to get it to run: build "all" or
> explicitly build it after you build the other individual thing you
> want?
>
>
>
>
> On Thu, May 18, 2017 at 10:24 AM, Robert Dailey
>  wrote:
>> David,
>>
>> Thanks for your help. So if I do it as you suggest, this will also
>> require I specify `ALL` to add_custom_target(), correct? If I do it
>> this way, will it still run even if it isn't a dependency of the
>> target I'm building?
>>
>> Let me set up a simple scenario for my own understanding. Suppose I
>> have the following targets:
>>
>> * A (add_library target)
>> * B (add_library target)
>> * C (add_custom_target target)
>>
>> Dependencies:
>>
>> B depends on A
>> C depends on B and A
>>
>> Normally if I build B, only A and B will build. However, if C was set
>> up using `ALL`, will it build C when I build B? So the expected build
>> order in this case would be:
>>
>> 1. A
>> 2. B
>> 3. C
>>
>> Thanks in advance.
>>
>> On Wed, May 17, 2017 at 4:26 PM, David Cole  wrote:
>>> The way I know how to do this is to add it last at the bottom of the
>>> top-level CMakeLists.txt file, and then use add_dependencies to make
>>>

Re: [CMake] Force target to always run last?

2017-05-18 Thread David Cole via CMake

I'm sorry, I misunderstood that you wanted it to run last regardless
of what target you are building. I was assuming you wanted it to
happen when you build the "all" target. I didn't think you wanted to
run it after any other *individual* target which you might specify.

I don't know of an easy way to do that. You could add a custom command
as a post-build command on every single target, but that seems like it
wouldn't work for you either, as it would run the command potentially
multiple times, with no way to tell whether you're being called last
or not.

Sorry.

Why does this need to run after the build of any individual target?
Why not just say there are two ways to get it to run: build "all" or
explicitly build it after you build the other individual thing you
want?




On Thu, May 18, 2017 at 10:24 AM, Robert Dailey
 wrote:
> David,
>
> Thanks for your help. So if I do it as you suggest, this will also
> require I specify `ALL` to add_custom_target(), correct? If I do it
> this way, will it still run even if it isn't a dependency of the
> target I'm building?
>
> Let me set up a simple scenario for my own understanding. Suppose I
> have the following targets:
>
> * A (add_library target)
> * B (add_library target)
> * C (add_custom_target target)
>
> Dependencies:
>
> B depends on A
> C depends on B and A
>
> Normally if I build B, only A and B will build. However, if C was set
> up using `ALL`, will it build C when I build B? So the expected build
> order in this case would be:
>
> 1. A
> 2. B
> 3. C
>
> Thanks in advance.
>
> On Wed, May 17, 2017 at 4:26 PM, David Cole  wrote:
>> The way I know how to do this is to add it last at the bottom of the
>> top-level CMakeLists.txt file, and then use add_dependencies to make
>> it depend on all other targets. (Or at least all other "leaf" targets,
>> which further depend on others, ... the sum of which is "all other
>> targets" besides the new "last" target.)
>>
>> So it's not pretty, but it's possible.
>>
>>
>> HTH,
>> David C.
>>
>>
>>
>> On Wed, May 17, 2017 at 11:36 AM, Robert Dailey
>>  wrote:
>>> I have a custom target that must meet the following requirements:
>>>
>>> * It must always run, regardless of what subset of other targets are being 
>>> built
>>> * It must always be the very last thing run. In parallelized builds,
>>> it must wait until all other targets are done building before
>>> starting, so that it is the very last target run, and should not run
>>> in parallel  with others.
>>>
>>> Is this possible? I'm willing to use hackery if needed...
>>>
>>> Running CMake 3.8.0. 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
-- 

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] Force target to always run last?

2017-05-18 Thread Robert Dailey

David,

Thanks for your help. So if I do it as you suggest, this will also
require I specify `ALL` to add_custom_target(), correct? If I do it
this way, will it still run even if it isn't a dependency of the
target I'm building?

Let me set up a simple scenario for my own understanding. Suppose I
have the following targets:

* A (add_library target)
* B (add_library target)
* C (add_custom_target target)

Dependencies:

B depends on A
C depends on B and A

Normally if I build B, only A and B will build. However, if C was set
up using `ALL`, will it build C when I build B? So the expected build
order in this case would be:

1. A
2. B
3. C

Thanks in advance.

On Wed, May 17, 2017 at 4:26 PM, David Cole  wrote:
> The way I know how to do this is to add it last at the bottom of the
> top-level CMakeLists.txt file, and then use add_dependencies to make
> it depend on all other targets. (Or at least all other "leaf" targets,
> which further depend on others, ... the sum of which is "all other
> targets" besides the new "last" target.)
>
> So it's not pretty, but it's possible.
>
>
> HTH,
> David C.
>
>
>
> On Wed, May 17, 2017 at 11:36 AM, Robert Dailey
>  wrote:
>> I have a custom target that must meet the following requirements:
>>
>> * It must always run, regardless of what subset of other targets are being 
>> built
>> * It must always be the very last thing run. In parallelized builds,
>> it must wait until all other targets are done building before
>> starting, so that it is the very last target run, and should not run
>> in parallel  with others.
>>
>> Is this possible? I'm willing to use hackery if needed...
>>
>> Running CMake 3.8.0. 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
-- 

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] CTest question

2017-05-18 Thread T.Sariyski

Hi Eric,

 

I am sorry I did not state the question clear enough. Let me first say that 
tests does not depend on each other, and  running with or without –parallel 
does not make much of difference.

 

Here is how I set the tests . This is a Fortran code, it does not return. 
ADD_TEST command is a call to CMAKE, which (i) executes the Fortran code, and 
(ii) executes a python script, a metrics of how close the solution is to the 
reference data. I have a PASS_REGULAR_EXPRESSION property,  passRegex, 
associated with the test. When a test fails, the output is that the required 
regular expression ${passRegex} is not found. A test and the python script are 
attached. Please let me know if more information is needed. 

 

Thanks in advance,

Ted

 

 

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

project(project_name Fortran ) 

enable_testing()

 

set (SRUN_COMMAND /bin/sh -c "cd ${ CMAKE_CURRENT_BINARY_DIR } &&  
$ ${PROJECT_NAME}")

add_custom_target(${PROJECT_NAME}_srun COMMAND ${SRUN_COMMAND})

set(TARGET_NAME ${PROJECT_NAME}_serial)

add_test(NAME ${TARGET_NAME}

   WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}

   COMMAND ${CMAKE_COMMAND} 

 -D "PRE_DELETE_OUTPUT_FILES:BOOL=true" 

 -D "OUTPUT_FILES:STRING=${files_to_delete}" 

 -D "PROGRAM1:STRING=${SRUN_COMMAND}" 

 -D 
"PROGRAM2:STRING=python;${assert_case};${hs_work_file};${hs_gold_file};0"   
  

 -P "run_and_assert.cmake")

 

set(passRegex "CALCULATION TERMINATED BECAUSE STOP TIME ACHIEVED" "ctest: 
SUCCESS")

set_property(TEST ${TARGET_NAME}

 PROPERTY PASS_REGULAR_EXPRESSION "${passRegex}")



 

/> cat run_and_assert.cmake

…

EXECUTE_PROCESS(COMMAND ${PROGRAM1}

RESULT_VARIABLE error

ERROR_FILE err.log

OUTPUT_FILE out.log

)

IF(error)

MESSAGE(FATAL_ERROR "Executing \"${PROGRAM1}\" FAIED! error=${error}")

ENDIF()

 

EXECUTE_PROCESS(COMMAND ${PROGRAM2}

RESULT_VARIABLE status)

IF(status)

MESSAGE(SEND_ERROR "Executing \"${PROGRAM2}\" FAILED! status=${status}")

ENDIF()

 

 

 

From: Eric Noulard [mailto:eric.noul...@gmail.com] 
Sent: Wednesday, May 17, 2017 10:54 PM
To: T.Sariyski 
Cc: CMake ML 
Subject: Re: [CMake] CTest question

 

We lack information on how your test are failing. If they all timeout then may 
be you should setup a proper timeout for the test. The actual execution speed 
of a test may depend on the load of your machine or the network (depending on 
what the test are actually doing).

This may be even more sensible if your test are run in parallel. Do you run 
ctest with --parallel option? 

 

Do your tests depends on each other? If so did you setup test dependencies?

 

Le 17 mai 2017 10:59 PM, "T.Sariyski"  > a écrit :

Hi,

 

I wonder what is the reason that sometimes ctest ends with numerous ‘Failed’ 
and ‘Timeout’, which ‘ctest –rerun-failed’ reports ‘Passed’. At times the 
number of these false failures is about one third. I guess that the problem is 
in the way I set my tests, but I have no clue where to look, or how to ‘debug’ 
the ctest run.

Any advice is highly appreciated.

 

Thanks,

Ted


--

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-commits] CMake branch, master, updated. v3.8.1-1231-gbc7d64f

2017-05-18 Thread Kitware Robot

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  bc7d64f896d6e180970cb404cc7699732db34adc (commit)
   via  44f8f839cbdddcb756bdb561b0905933e7551867 (commit)
   via  9e24af01375d370ae84c40a95501aa5a33d3fe97 (commit)
   via  9e06e97d30faf0916bec404c81922334139cf177 (commit)
  from  10371cd6dcfc1bf601fa3e715734dbe66199e2e4 (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=bc7d64f896d6e180970cb404cc7699732db34adc
commit bc7d64f896d6e180970cb404cc7699732db34adc
Merge: 44f8f83 9e24af0
Author: Brad King 
AuthorDate: Thu May 18 13:03:34 2017 +
Commit: Kitware Robot 
CommitDate: Thu May 18 09:03:40 2017 -0400

Merge topic 'string-append'

9e24af01 Use string(APPEND) in Modules

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=44f8f839cbdddcb756bdb561b0905933e7551867
commit 44f8f839cbdddcb756bdb561b0905933e7551867
Merge: 10371cd 9e06e97
Author: Brad King 
AuthorDate: Thu May 18 13:01:53 2017 +
Commit: Kitware Robot 
CommitDate: Thu May 18 09:01:57 2017 -0400

Merge topic 'cpack-archive-per-component-filename'

9e06e97d CPack/Archive: per component filenames support

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e24af01375d370ae84c40a95501aa5a33d3fe97
commit 9e24af01375d370ae84c40a95501aa5a33d3fe97
Author: Daniel Pfeifer 
AuthorDate: Wed May 17 11:23:34 2017 -0600
Commit: Daniel Pfeifer 
CommitDate: Wed May 17 11:26:11 2017 -0600

Use string(APPEND) in Modules

Automate with:

find Modules -type f -print0 | xargs -0 perl -i -0pe \
  's/set\(([a-zA-Z0-9_\$\{\}]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'

diff --git a/Modules/CMakeCompilerIdDetection.cmake 
b/Modules/CMakeCompilerIdDetection.cmake
index 7ca79bd..f2d43b6 100644
--- a/Modules/CMakeCompilerIdDetection.cmake
+++ b/Modules/CMakeCompilerIdDetection.cmake
@@ -95,13 +95,13 @@ function(compiler_id_detection outvar lang)
 
 if(CID_ID_DEFINE)
   foreach(Id ${ordered_compilers})
-set(CMAKE_${lang}_COMPILER_ID_CONTENT 
"${CMAKE_${lang}_COMPILER_ID_CONTENT}# define ${CID_PREFIX}COMPILER_IS_${Id} 
0\n")
+string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT "# define 
${CID_PREFIX}COMPILER_IS_${Id} 0\n")
   endforeach()
 endif()
 
 set(pp_if "#if")
 if (CID_VERSION_STRINGS)
-  set(CMAKE_${lang}_COMPILER_ID_CONTENT 
"${CMAKE_${lang}_COMPILER_ID_CONTENT}\n/* Version number components: V=Version, 
R=Revision, P=Patch
+  string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT "\n/* Version number 
components: V=Version, R=Revision, P=Patch
Version date components:   =Year, MM=Month,   DD=Day  */\n")
 endif()
 
@@ -126,7 +126,7 @@ function(compiler_id_detection outvar lang)
 string(CONFIGURE "${_compiler_id_version_compute_${Id}}" VERSION_BLOCK 
@ONLY)
 string(APPEND id_content "${VERSION_BLOCK}\n")
   endif()
-  set(CMAKE_${lang}_COMPILER_ID_CONTENT 
"${CMAKE_${lang}_COMPILER_ID_CONTENT}\n${id_content}")
+  string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT "\n${id_content}")
   set(pp_if "#elif")
 endforeach()
 
@@ -145,7 +145,7 @@ function(compiler_id_detection outvar lang)
 # define ${CID_PREFIX}COMPILER_ID \"\"")
 endif()
 
-set(CMAKE_${lang}_COMPILER_ID_CONTENT 
"${CMAKE_${lang}_COMPILER_ID_CONTENT}\n${platform_compiler_detection}\n#endif")
+string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT 
"\n${platform_compiler_detection}\n#endif")
   endif()
 
   set(${outvar} ${CMAKE_${lang}_COMPILER_ID_CONTENT} PARENT_SCOPE)
diff --git a/Modules/CPackComponent.cmake b/Modules/CPackComponent.cmake
index 2adc9b9..3a10b99 100644
--- a/Modules/CPackComponent.cmake
+++ b/Modules/CPackComponent.cmake
@@ -309,11 +309,11 @@ set(CPackComponent_CMake_INCLUDED 1)
 # configuration file.
 macro(cpack_append_variable_set_command var strvar)
   if (DEFINED ${var})
-set(${strvar} "${${strvar}}set(${var}")
+string(APPEND ${strvar} "set(${var}")
 foreach(APPENDVAL ${${var}})
-  set(${strvar} "${${strvar}} ${APPENDVAL}")
+  string(APPEND ${strvar} " ${APPENDVAL}")
 endforeach()
-set(${strvar} "${${strvar}})\n")
+string(APPEND ${strvar} ")\n")
   endif ()
 endmacro()
 
@@ -325,7 +325,7 @@ macro(cpack_append_string_variable_set_command var strvar)
   if (DEFINED ${var})

Re: [CMake] Force target to always run last?

2017-05-18 Thread Patrick Boettcher

On Wed, 17 May 2017 10:36:59 -0500
Robert Dailey  wrote:

> I have a custom target that must meet the following requirements:
> 
> * It must always run, regardless of what subset of other targets are
> being built
> * It must always be the very last thing run. In parallelized builds,
> it must wait until all other targets are done building before
> starting, so that it is the very last target run, and should not run
> in parallel  with others.
> 
> Is this possible? I'm willing to use hackery if needed...
> 
> Running CMake 3.8.0. Thanks!

One way would be to create a super-project-like CMakeLists.txt which
will add your current project via ExternalProject_Add() .

Then you add your always-build-last-target to this super-CMakeLists.txt
as depending on the target created by this external-project in this
super-CMakeLists.txt .

regards,
--
Patrick.

-- 

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] Link order and interface multiplicity

2017-05-18 Thread Patrick Boettcher

On Wed, 17 May 2017 21:15:39 +
Etan Kissling  wrote:

> Not sure if I understand that correctly, but isn't that essential the
> same as creating a FooA and BarA that link to IA, and a FooB and BarB
> that link to IB, and linking ExeA to FooA and ExeB to FooB?
> 
> Problem with this approach is that there are more than two
> implementations of I, and way more than two Exes ^_^
 
Could you create an example repository (on github for example) which
templates what you're trying to achieve?

>From what I understood so far, I doubt that all of it can be
achieved in one cmake-build. Maybe you need to create a super-project
and work with export() and include(). 

regards,
--
Patrick.




-- 

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] RPATH for external library

2017-05-18 Thread Patrick Boettcher

On Wed, 17 May 2017 17:13:13 -0700
Pawel Veselov  wrote:

> On Wed, May 17, 2017 at 2:55 AM, Patrick Boettcher
> > My reason of preferring pkg-config is
> because it may have all
> >> other kind of stuff in it that the maintainer thought is necessary.
> >> I'd imagine some .pc files export a boatload of flags for all 3
> >> stages, and I rather not ignored them. It is also quite important
> >> when there are chained dependencies.  
> >
> > Understandable.
> >
> > If I understand things correctly, pkg-config does not return the
> > RPATH-arguments necessary to link with. IOW, if used in a GNU
> > Makefile you would also need to add these by yourself, right? So
> > your problem is not a cmake-problem.  
> 
> IMHO it's not fair to say - if it's not supported by GNUmake, it
> shouldn't be supported by CMake.

That was not my intention to say. But rather I thought that somewhere
this problem was already solved, as it is not a cmake-only-problem, but
a general build problem when using pkg-config on libraries which are not
in default search-pathes.
 
> In any case, the CMake documentation says that
> INSTALL_RPATH_USE_LINK_PATH "...will append directories in the linker
> search path and outside the project to the INSTALL_RPATH...", there
> is no statement that it only applies to linker search paths that were
> supplied in a certain way.

That applies only to libraries, not the linker-flags which have
been added behind the back of cmake's library-dependency mechanism. 

> [skipped]

This skipped part was trying to point out a solution based on the -l
and -L arguments returned by pkg-config and some cmake parsing. It
wouldn't be beautiful, but it'll work.

--
Patrick.
-- 

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] cmake to download and compile fftw library

[Cmake-commits] CMake branch, master, updated. v3.8.1-1232-gde41f3b

[cmake-developers] Compile targets affected by changeset

Re: [CMake] Force target to always run last?

Re: [CMake] Force target to always run last?

[cmake-developers] Making your regular expression engine more reliable

Re: [CMake] Force target to always run last?

Re: [CMake] Force target to always run last?

Re: [CMake] RPATH for external library

Re: [CMake] FW: CTest question

[CMake] FW: CTest question

Re: [CMake] Force target to always run last?

Re: [CMake] Force target to always run last?

Re: [CMake] Force target to always run last?

Re: [CMake] CTest question

[Cmake-commits] CMake branch, master, updated. v3.8.1-1231-gbc7d64f

Re: [CMake] Force target to always run last?

Re: [CMake] Link order and interface multiplicity

Re: [CMake] RPATH for external library

19 matches

Site Navigation

Mail list logo

Footer information