Thanks for your comments, Brad.
I added a patch to convert the file(WRITE) calls in
_ep_write_log_script to file(GENERATE) calls. It works OK in my tests,
but honestly I'm not confident enough in those changes. Any test
recommendations?
I also added a patch to write init and log scripts to
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15525
==
Reported By:Nils Gladitz
Assigned To:
As far as I understand, IMPORT libraries are for different purposes.
They should be used for files that are already exist. In other words,
to import existing artifacts into the build system. I don't remember
the exact details, but last time I tried to use IMPORT library for
such purpose there was
Andrey Pokrovskiy wrote:
In my case openssl is also generated as a result of an external
project, so I have to use INTERFACE library.
Ah, ok. I missed that part.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 04/21/2015 12:17 PM, Andrey Pokrovskiy wrote:
I understand that, but I still don't understand why there is a need in
file-level dependencies at all. When target level dependency will not
be enough?
Each step of an external project has a timestamp file to track whether
it is up to date or
Le 20/04/15 22:23, Domen Vrankar a écrit :
Is there any other thing you would like to do before I continue working on
this? Do you foresee any other change like this?
No, go ahead.
Regards,
Domen
Please find attached the first patch that adds the tests to the Debian
packaging, and
[Moved from cmake users mailing list]
I have the following construction:
ExternalProject_Add(
websockets_ep
DEPENDS ev openssl
...)
But it so happened, that openssl is an INTERFACE library. It is an
INTERFACE library, because I created it with add_library(openssl
Hi,
I'm trying to figure out what is the best way to use 'find_dependency'
if dependent package is optional (e.g. can be controlled by some build
option):
# CMakeLists.txt
option(BOO_WITH_FOO Build Boo with Foo ON)
if(BOO_WITH_FOO)
find_package(Foo CONFIG REQUIRED)
Le 21/04/15 16:41, Raffi Enficiaud a écrit :
Le 21/04/15 14:36, Raffi Enficiaud a écrit :
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2)
Le 21/04/15 14:36, Raffi Enficiaud a écrit :
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component
On 04/21/2015 02:58 AM, Andrey Pokrovskiy wrote:
Full patch set attached.
Thanks. I added some test infrastructure and then updated your
patch to use it to cover the new behavior. I also tweaked the
patches to add documentation and reference a relevant issue.
Applied:
ExternalProject: Allow
Le 18/04/15 09:58, Raffi Enficiaud a écrit :
Le 18/04/15 09:34, Domen Vrankar a écrit :
The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per
To avoid this entirely, you can just use add_dependencies (
http://www.cmake.org/cmake/help/v3.2/command/add_dependencies.html )
instead of adding it as a DEPENDS to your ExternalProject_Add call.
The reason ExternalProject_Add queries to see if the other thing is an
ExternalProject or not is to
I do not know how you would like to proceed. It should not be any issue in
applying the patches in sequence from the changes you made yesterday.
Hi,
I just started applying and reviewing the patches. It will take me a
while to get through them. I'll write to you after I'm done.
Thanks,
Domen
On 04/21/2015 03:34 AM, Andrey Pokrovskiy wrote:
CMake Error at
/usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031
(get_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property _EP_IS_EXTERNAL_PROJECT is not allowed.
Call Stack (most
Le 21/04/15 23:01, Domen Vrankar a écrit :
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
Hi all,
There was an old thread
http://public.kitware.com/pipermail/cmake-developers/2014-November/023743.html
from November of last year discussing fixes for
compilation with MinGW-W64. As far as I can tell, no patch was ever
merged. Here's a patch against the current master that fixes the issue.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15526
==
Reported By:Dan Kegel
Assigned To:
Andrey Pokrovskiy wrote:
[Moved from cmake users mailing list]
I have the following construction:
ExternalProject_Add(
websockets_ep
DEPENDS ev openssl
...)
But it so happened, that openssl is an INTERFACE library. It is an
INTERFACE library, because I
Hi,
I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9
Please find attached my last patch that allows the settings of the
dependencies per component.
I haven't finished
Thanks for fixing that, Brad!
Why there is a special case when dependency is also an external project?
When one external project depends on another then we add both
the target-level ordering dependencies (add_dependencies) and
add file-level dependencies on the stamp files so that things
21 matches
Mail list logo
