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
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
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
h
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
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.
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 execu
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
>> > 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 support
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
ind
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
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' d
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
e
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://
13 matches
Mail list logo
