Re: [CMake] Calling find_package(self) for in-project builds

2016-06-02 Thread Konstantin Podsvirov
Hello.8:34, 3 june 2016 г., Walter Gray :Interesting idea, that could be possible.Possible, but realy need? It can be alternative. Now we can use ALIASES for build tree configuration - It's work (I check)On Thu, Jun 2, 2016 at 8:45 PM Dan Liew  wrote:> What would be the suggested way to handle this?  Couldn't you build the examples using CMake's ``ExternalProject`` module [1] and have that build after the main project has finished building?  [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html  -- Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow 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] Calling find_package(self) for in-project builds

2016-06-02 Thread Walter Gray
Interesting idea, that could be possible.

On Thu, Jun 2, 2016 at 8:45 PM Dan Liew  wrote:

> > What would be the suggested way to handle this?
>
> Couldn't you build the examples using CMake's ``ExternalProject``
> module [1] and have that build after the main project has finished
> building?
>
> [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html
>
-- 

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] Calling find_package(self) for in-project builds

2016-06-02 Thread Dan Liew
> What would be the suggested way to handle this?

Couldn't you build the examples using CMake's ``ExternalProject``
module [1] and have that build after the main project has finished
building?

[1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html
-- 

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] Calling find_package(self) for in-project builds

2016-06-02 Thread Walter Gray
That only gets me part way - there's also the issue of the options & extra
functions defined in protobuf-config.in. My best guess ATM would be to do
something simmilar and create namespaced aliases, then just not include the
protobuf-targets.cmake file from protobuf-config.cmake if
CMAKE_CURRENT_LIST_DIR STREQUAL CMAKE_BINARY_DIR.

On Thu, Jun 2, 2016 at 6:16 PM Nicholas Braden 
wrote:

> Although not ideal, you could alias the targets to the names they
> would have when imported with find_package() by using
> add_library(ALIAS), and then use if(TARGET) to conditionally call
> find_package(). This also is a step toward supporting using the
> library via add_subdirectory(), if that ever becomes a goal.
>
> On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray  wrote:
> > I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a
> bit
> > of a chicken and egg problem.
> >
> > There is an examples directory containing a CMakeLists.txt which we would
> > like to work as both a standalone examples directory and include as a sub
> > directory of the full build. For obvious reasons, the CMakeLists.txt file
> > contains a call to find_package(protobuf).
> >
> > I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of
> the
> > examples/CMakeLists.txt file to ensure that we've already found the
> correct
> > version, but the problem is that the protobuf-config.cmake file includes
> the
> > export-generated file protobuf-targets.cmake, as well as implementing
> some
> > custom functions that we want to show off as part of the examples.
> >
> > The obvious solution to me was to use the export command to generate
> > protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT)
> > doesn't create a file until generation time, but I can get around this
> using
> > export(TARGETS). The second is that, reading CMP0024, this appears to be
> not
> > garunted behavior, and actively discouraged.
> >
> > What would be the suggested way to handle this?
> >
> > --
> >
> > 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] execute short program during cmake configuration ?

2016-06-02 Thread Guy Harris
On Jun 2, 2016, at 2:56 PM, Alan W. Irwin  wrote:

> It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS
> macro. So I suggest you copy that macro (found in
> Modules/CheckCSourceRuns.cmake) to your own source code where your
> other home-grown CMake macros are located, rename that macro to
> CHECK_FORTRAN_SOURCE_RUNS, and make the minor modifications to that
> macro that are appropriate for the Fortran case.

...and contribute it back to the CMake maintainers to encourage its appearance 
in future releases?
-- 

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] Calling find_package(self) for in-project builds

2016-06-02 Thread Nicholas Braden
Although not ideal, you could alias the targets to the names they
would have when imported with find_package() by using
add_library(ALIAS), and then use if(TARGET) to conditionally call
find_package(). This also is a step toward supporting using the
library via add_subdirectory(), if that ever becomes a goal.

On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray  wrote:
> I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit
> of a chicken and egg problem.
>
> There is an examples directory containing a CMakeLists.txt which we would
> like to work as both a standalone examples directory and include as a sub
> directory of the full build. For obvious reasons, the CMakeLists.txt file
> contains a call to find_package(protobuf).
>
> I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of the
> examples/CMakeLists.txt file to ensure that we've already found the correct
> version, but the problem is that the protobuf-config.cmake file includes the
> export-generated file protobuf-targets.cmake, as well as implementing some
> custom functions that we want to show off as part of the examples.
>
> The obvious solution to me was to use the export command to generate
> protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT)
> doesn't create a file until generation time, but I can get around this using
> export(TARGETS). The second is that, reading CMP0024, this appears to be not
> garunted behavior, and actively discouraged.
>
> What would be the suggested way to handle this?
>
> --
>
> 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] Calling find_package(self) for in-project builds

2016-06-02 Thread Walter Gray
I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit
of a chicken and egg problem.

There is an examples directory containing a CMakeLists.txt which we would
like to work as both a standalone examples directory and include as a sub
directory of the full build. For obvious reasons, the CMakeLists.txt file
contains a call to find_package(protobuf).

I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of the
examples/CMakeLists.txt file to ensure that we've already found the correct
version, but the problem is that the protobuf-config.cmake file includes
the export-generated file protobuf-targets.cmake, as well as implementing
some custom functions that we want to show off as part of the examples.

The obvious solution to me was to use the export command to generate
protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT)
doesn't create a file until generation time, but I can get around this
using export(TARGETS). The second is that, reading CMP0024, this appears to
be not garunted behavior, and actively discouraged.

What would be the suggested way to handle this?
-- 

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] execute short program during cmake configuration ?

2016-06-02 Thread Alan W. Irwin

On 2016-06-02 20:10- Ilias Miroslav wrote:



Greetings, dear experts,


we have (two) short Fortran programs (detection of integer*4/8 for math 
libraries) which we would like to build and execute during project's  
configuration phase.


There is the " CheckFortranSourceCompiles" command to compile a Fortran source 
code during project's  configure time.  However, we would be glad also to execute the 
resulting a.out binary and check if it passes or crashes.


Any help, please ? Is there a way to compile/execute short program in the 
configuration  stage of the (big) project ?


Hi Ilias:

It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS
macro. So I suggest you copy that macro (found in
Modules/CheckCSourceRuns.cmake) to your own source code where your
other home-grown CMake macros are located, rename that macro to
CHECK_FORTRAN_SOURCE_RUNS, and make the minor modifications to that
macro that are appropriate for the Fortran case.

By the way, such copy and modification is permitted/encouraged by the
copyright license for CMake as given in Modules/CheckCSourceRuns.cmake
although as that source file licensing text summary says you do have
to put the full text of the license in that modified file.

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


Re: [CMake] execute short program during cmake configuration ?

2016-06-02 Thread Craig Scott
It might be overkill for what you want, but this stack overflow question
 deals with a very similar
situation.


On Fri, Jun 3, 2016 at 6:10 AM, Ilias Miroslav 
wrote:

>
> Greetings, dear experts,
>
>
> we have (two) short Fortran programs (detection of integer*4/8 for math
> libraries) which we would like to build and execute during project's
> configuration phase.
>
>
> There is the " CheckFortranSourceCompiles" command to compile a Fortran
> source code during project's  configure time.  However, we would be glad
> also to execute the resulting a.out binary and check if it passes or
> crashes.
>
>
> Any help, please ? Is there a way to compile/execute short program in the
> configuration  stage of the (big) project ?
>
>
> Yours, Miro
>
> ( CMake co-builder for http://www.diracprogram.org  )
>
>
>
>
> --
>
> 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
>



-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-- 

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] execute short program during cmake configuration ?

2016-06-02 Thread Ilias Miroslav

Greetings, dear experts,


we have (two) short Fortran programs (detection of integer*4/8 for math 
libraries) which we would like to build and execute during project's  
configuration phase.


There is the " CheckFortranSourceCompiles" command to compile a Fortran source 
code during project's  configure time.  However, we would be glad also to 
execute the resulting a.out binary and check if it passes or crashes.


Any help, please ? Is there a way to compile/execute short program in the 
configuration  stage of the (big) project ?


Yours, Miro

( CMake co-builder for http://www.diracprogram.org  )


-- 

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] add_custom_command, POST_BUILD

2016-06-02 Thread iosif neitzke
On Thu, Jun 2, 2016 at 2:43 PM, Chuck Atkins  wrote:
> Could you just make the tests run in the post-build of the test?
>
> add_library(Foo Foo.cxx)
>
> add_executable(FooTest FooTest.cxx)
> target_link_libraries(FooTest Foo)
>
> add_custom_command(TARGET FooTest POST_BUILD
>   COMMAND $ $
> )
>
> That way the the test is run as part of it's build.
>

This is what we do for our Unit Test projects.   We also register the
test executable with CTest's add_test too.

>
> - Chuck
>
> On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev
>  wrote:
>>
>> Hi there.
>>
>> At the moment one can add a command executing after a build of a target
>> using:
>> add_custom_command(... POST_BUILD...)
>>
>> However if the command have a dependencies which build after the target,
>> there is practically no way to specify it.
>>
>> Simple case: we have a library and tests for it. E.g. I want them to run
>> in POST_BUILD of a library. But, tests already depends on the library so I
>> can't make them built before it.
>>
>> There are few possible solutions to that:
>> 1) add possibility to set dependencies for add_custom_command in
>> POST_BUILD mode;
>> 2) add possibility to populate list of targets if we have specified ones
>> in list.
>>
>> Or maybe correct me if I miss something.
>>
>> Kind regards, Vladimir.
>>
>>
>> --
>>
>> 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
-- 

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] add_custom_command, POST_BUILD

2016-06-02 Thread Chuck Atkins
Could you just make the tests run in the post-build of the test?

add_library(Foo Foo.cxx)

add_executable(FooTest FooTest.cxx)
target_link_libraries(FooTest Foo)

add_custom_command(TARGET FooTest POST_BUILD
  COMMAND $ $
)

That way the the test is run as part of it's build.


- Chuck

On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev <
vladimir.chebota...@gmail.com> wrote:

> Hi there.
>
> At the moment one can add a command executing after a build of a target
> using:
> add_custom_command(... POST_BUILD...)
>
> However if the command have a dependencies which build after the target,
> there is practically no way to specify it.
>
> Simple case: we have a library and tests for it. E.g. I want them to run
> in POST_BUILD of a library. But, tests already depends on the library so I
> can't make them built before it.
>
> There are few possible solutions to that:
> 1) add possibility to set dependencies for add_custom_command in
> POST_BUILD mode;
> 2) add possibility to populate list of targets if we have specified ones
> in list.
>
> Or maybe correct me if I miss something.
>
> Kind regards, Vladimir.
>
> --
>
> 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] add_custom_command, POST_BUILD

2016-06-02 Thread Vladimir Chebotarev
Hi.

The reason is to make build to fail as soon as possible if core library doesn't 
work properly. In C++ world that could be critical as hell because building 
process can last hours even on 32 cores.

And it will make CMake more ecological tool as it will reduce the energy 
wasted. :)

On Jun 1, 2016, Magnus Therning  wrote:
>
>Vladimir Chebotarev  writes:
>
>> Hi there.
>>
>> At the moment one can add a command executing after a build of a
>target
>> using:
>> add_custom_command(... POST_BUILD...)
>>
>> However if the command have a dependencies which build after the
>target,
>> there is practically no way to specify it.
>>
>> Simple case: we have a library and tests for it. E.g. I want them to
>run in
>> POST_BUILD of a library. But, tests already depends on the library so
>I
>> can't make them built before it.
>>
>> There are few possible solutions to that:
>> 1) add possibility to set dependencies for add_custom_command in
>POST_BUILD
>> mode;
>> 2) add possibility to populate list of targets if we have specified
>ones in
>> list.
>>
>> Or maybe correct me if I miss something.
>
>Have you not simply missed add_test()? ;)
>
>What's the reason for wanting the tests to run post-build, rather than
>on `make test`?
>
>/M

Kind regards,
Vladimir.
-- 

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] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

2016-06-02 Thread Brad King
On 06/01/2016 04:54 PM, Chuck Atkins wrote:
> Wow, so this is actually a pretty obscure find.  You've definitely stumbled
> across a bug.  It has nothing to do with debug symbols and everything to do
> with compiler identification.  It seems that our binary strings parsing is
> broken when "[anything]" is in the file path.

This should fix it:

 CMakeDetermineCompilerId: Fix compiler id with square brackets in the path
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7d1c4ec

-Brad

-- 

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] MSYS Makefiles generator problem with install/strip

2016-06-02 Thread Robert Bielik
Cheers Hendrik,



I'll try to use that approach. Thanx!



Regards

/R



Skickat från min LG-Mobil





-- Ursprungligt meddelande--

Från: Hendrik Sattler

Datum: tors, 2 jun 2016 20:32

Till: Robert Bielik;cmake@cmake.org;

Ämne:Re: [CMake] MSYS Makefiles generator problem with install/strip



Hi,

Am 2. Juni 2016 19:23:26 MESZ, schrieb Robert Bielik :
>Hi Hendrik,
>
>
>
>I think I do, yes. Would this not be a normal use case, specifically on
>Linux, where the bin library would be /usr/bin? How would that work
>with relative paths?

Installation is always relative to CMAKE_INSTALL_PREFIX. On Linux, this 
defaults to /usr/local. Using the variables from GNUInstallDirs module saves 
you lots of trouble like library locations on Debian or Rehat.
It's actually pretty simple and only very special cases differ from this.

>I think it would be a bug if install cannot handle arbitrary paths.

The problem is the drive letter of the absolute path that can hardly be 
concatenated with a staging folder that you can define with DESTDIR like
  make install DESTDIR=mystagedir

and the files go to their relative locations in
//

You gain a lot more flexibility by adopting this than hard encoding path in the 
install() commands.

>I'll try though to see if I can work around this... behavior...



Regards,

HS

>-- Ursprungligt meddelande--
>
>Från: Hendrik Sattler
>
>Datum: tors, 2 jun 2016 19:16
>
>Till: Robert Bielik;cmake@cmake.org;
>
>Ämne:Re: [CMake] MSYS Makefiles generator problem with install/strip
>
>
>
>Hi,
>
>Are you using absolute paths in your install() commands? You better
>don't.
>
>HS
>
>
>Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik
>:
>>Hi,
>>
>>I have a problem with the install/strip target not working when using
>>the MSYS Makefiles generator. I get the following result in
>>cmake_install.cmake:
>>
>>file(INSTALL DESTINATION
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>>if(EXISTS
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so
>>" AND
>>NOT IS_SYMLINK
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>if(CMAKE_INSTALL_DO_STRIP)
>>execute_process(COMMAND
>>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>endif()
>>  endif()
>>endif()
>>
>>The above should instead look like:
>>
>>file(INSTALL DESTINATION
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>>if(EXISTS
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so"
>>AND
>>NOT IS_SYMLINK
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>if(CMAKE_INSTALL_DO_STRIP)
>>execute_process(COMMAND
>>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>endif()
>>  endif()
>>endif()
>>
>>Then the install/strip target works.
>>
>>Regards
>>/Robert
>
>--
>Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.
>
>
>

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] MSYS Makefiles generator problem with install/strip

2016-06-02 Thread Hendrik Sattler
Hi,

Am 2. Juni 2016 19:23:26 MESZ, schrieb Robert Bielik :
>Hi Hendrik,
>
>
>
>I think I do, yes. Would this not be a normal use case, specifically on
>Linux, where the bin library would be /usr/bin? How would that work
>with relative paths?

Installation is always relative to CMAKE_INSTALL_PREFIX. On Linux, this 
defaults to /usr/local. Using the variables from GNUInstallDirs module saves 
you lots of trouble like library locations on Debian or Rehat.
It's actually pretty simple and only very special cases differ from this.

>I think it would be a bug if install cannot handle arbitrary paths.

The problem is the drive letter of the absolute path that can hardly be 
concatenated with a staging folder that you can define with DESTDIR like
  make install DESTDIR=mystagedir

and the files go to their relative locations in
//

You gain a lot more flexibility by adopting this than hard encoding path in the 
install() commands.

>I'll try though to see if I can work around this... behavior...



Regards,

HS

>-- Ursprungligt meddelande--
>
>Från: Hendrik Sattler
>
>Datum: tors, 2 jun 2016 19:16
>
>Till: Robert Bielik;cmake@cmake.org;
>
>Ämne:Re: [CMake] MSYS Makefiles generator problem with install/strip
>
>
>
>Hi,
>
>Are you using absolute paths in your install() commands? You better
>don't.
>
>HS
>
>
>Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik
>:
>>Hi,
>>
>>I have a problem with the install/strip target not working when using
>>the MSYS Makefiles generator. I get the following result in
>>cmake_install.cmake:
>>
>>file(INSTALL DESTINATION
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>>if(EXISTS
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so
>>" AND
>>NOT IS_SYMLINK
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>if(CMAKE_INSTALL_DO_STRIP)
>>execute_process(COMMAND
>>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>endif()
>>  endif()
>>endif()
>>
>>The above should instead look like:
>>
>>file(INSTALL DESTINATION
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>>if(EXISTS
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so"
>>AND
>>NOT IS_SYMLINK
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>if(CMAKE_INSTALL_DO_STRIP)
>>execute_process(COMMAND
>>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>>endif()
>>  endif()
>>endif()
>>
>>Then the install/strip target works.
>>
>>Regards
>>/Robert
>
>--
>Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] MSYS Makefiles generator problem with install/strip

2016-06-02 Thread Robert Bielik
Hi Hendrik,



I think I do, yes. Would this not be a normal use case, specifically on Linux, 
where the bin library would be /usr/bin? How would that work with relative 
paths?



I think it would be a bug if install cannot handle arbitrary paths.



I'll try though to see if I can work around this... behavior...



Regards

/R



Skickat från min LG-Mobil





-- Ursprungligt meddelande--

Från: Hendrik Sattler

Datum: tors, 2 jun 2016 19:16

Till: Robert Bielik;cmake@cmake.org;

Ämne:Re: [CMake] MSYS Makefiles generator problem with install/strip



Hi,

Are you using absolute paths in your install() commands? You better don't.

HS


Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik :
>Hi,
>
>I have a problem with the install/strip target not working when using
>the MSYS Makefiles generator. I get the following result in
>cmake_install.cmake:
>
>file(INSTALL DESTINATION
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>if(EXISTS
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so
>" AND
>NOT IS_SYMLINK
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>if(CMAKE_INSTALL_DO_STRIP)
>execute_process(COMMAND
>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>endif()
>  endif()
>endif()
>
>The above should instead look like:
>
>file(INSTALL DESTINATION
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>if(EXISTS
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so"
>AND
>NOT IS_SYMLINK
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>if(CMAKE_INSTALL_DO_STRIP)
>execute_process(COMMAND
>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>endif()
>  endif()
>endif()
>
>Then the install/strip target works.
>
>Regards
>/Robert

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] MSYS Makefiles generator problem with install/strip

2016-06-02 Thread Hendrik Sattler
Hi,

Are you using absolute paths in your install() commands? You better don't.

HS


Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik :
>Hi,
>
>I have a problem with the install/strip target not working when using
>the MSYS Makefiles generator. I get the following result in
>cmake_install.cmake:
>
>file(INSTALL DESTINATION
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>if(EXISTS
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so
>" AND
>NOT IS_SYMLINK
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>if(CMAKE_INSTALL_DO_STRIP)
>execute_process(COMMAND
>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>endif()
>  endif()
>endif()
>
>The above should instead look like:
>
>file(INSTALL DESTINATION
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE
>SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_native.so")
>if(EXISTS
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so"
>AND
>NOT IS_SYMLINK
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>if(CMAKE_INSTALL_DO_STRIP)
>execute_process(COMMAND
>"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
>"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
>endif()
>  endif()
>endif()
>
>Then the install/strip target works.
>
>Regards
>/Robert

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] CPack with BZIP2 is a lot slower than GNU tar

2016-06-02 Thread Bill Hoffman

On 6/2/2016 5:29 AM, Alessio wrote:

I'm comparing the following two things:
  1. cpack TBZ2 generator
  2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression)

I cannot avoid CPack. It takes care of way too many little details of
the packaging. Obviously we use it via lots of install() statements in
our CMakeLists.txt files.

Sounds like it needs some performance testing.   One thing to try would 
be to compare cmake -E tar with tar and see if it is libtar that is 
slow, or something CPack is doing.  After that, maybe calgrind or other 
tools to profile cpack.


-Bill

--

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] MSYS Makefiles generator problem with install/strip

2016-06-02 Thread Robert Bielik
Hi,

I have a problem with the install/strip target not working when using the MSYS 
Makefiles generator. I get the following result in cmake_install.cmake:

file(INSTALL DESTINATION 
"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE SHARED_LIBRARY 
FILES "C:/Dev/jniAndroid/libapi_native.so")
  if(EXISTS 
"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so
 " AND
 NOT IS_SYMLINK 
"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
if(CMAKE_INSTALL_DO_STRIP)
  execute_process(COMMAND 
"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
 
"$ENV{DESTDIR}/c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
endif()
  endif()
endif()

The above should instead look like:

file(INSTALL DESTINATION 
"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE SHARED_LIBRARY 
FILES "C:/Dev/jniAndroid/libapi_native.so")
  if(EXISTS 
"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so" AND
 NOT IS_SYMLINK 
"c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
if(CMAKE_INSTALL_DO_STRIP)
  execute_process(COMMAND 
"C:/android/android-ndk-r11c/standalone/arm/bin/arm-linux-androideabi-strip.exe"
 "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a/libapi_native.so")
endif()
  endif()
endif()

Then the install/strip target works.

Regards
/Robert

-- 

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] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

2016-06-02 Thread eschnigma
 

Renaming the folder did indeed fix it here. I tested with g++ and Clang,
both work fine.
This is on a different machine than I was posting from before, but it's
also running Manjaro.
I will test this on my main machine once I'm home, which will be be in
six hours or so, and I'll let you know the results. 

On 2016-06-01 23:54, Chuck Atkins wrote: 

> Wow, so this is actually a pretty obscure find. You've definitely stumbled 
> across a bug. It has nothing to do with debug symbols and everything to do 
> with compiler identification. It seems that our binary strings parsing is 
> broken when "[anything]" is in the file path. Without looking at the code too 
> deeply, i imagine something is not getting properly escaped somewhere. As a 
> workaround for now, rename your "[Code]" folder to "Code" and then it should 
> work (lame I know). I would ask you to please file a bug report but new user 
> registration is currently disabled due to some spam issues we were having. 
> I'll put it in the queue for issues to address in future releases but I doubt 
> it will make it into the 3.6 release since it seems to have been there for a 
> long time without affecting too many users but it should be able to get fixed 
> in a future release.
> 
> Once we open the bug tracker up again then please definitely report the issue 
> (unless you already have an account then go ahead and report it now). 
> 
> Thanks for the find! 
> 
> - Chuck 
> 
> On Wed, Jun 1, 2016 at 1:59 PM, Esch Nigma  wrote:
> 
>> I tried it out just now. 
>> 
>> I pulled and installed a couple 5.x packages from the Arch archive: 
>> 
>> https://archive.archlinux.org/packages/l/ [1] 
>> 
>> The packages: 
>> 
>> gcc-libs-multilib-5.3.0-4-x86_64.pkg.tar.xz 
>> 
>> gcc-multilib-5.3.0-4-x86_64.pkg.tar.xz 
>> 
>> lib32-gcc-libs-5.3.0-4-x86_64.p 
>> 
>> The downgrade didn't change anything for my Hello World program. 
>> 
>> For the project I'm actively working on, it broke everything, since C++11 is 
>> no longer recognized. 
>> 
>> On my system I had to pull the 'multilib' versions, as this is what my 
>> system seems to be using. If requested, I can try to switch to normal gcc to 
>> test that out. 
>> 
>> On Wednesday, June 1, 2016 11:46:40 AM EEST Chuck Atkins wrote: 
>> 
>> Interesting. It seems CMake is having trouble identifying GCC in 6.1.1. Do 
>> you have a 5.x compiler available? If so does it work with that? That would 
>> help narrow it down to a gcc6 issue vs something about how Manjaro packages 
>> compilers. 
>> 
>> - Chuck 
>> 
>> On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma  
>> wrote: 
>> 
>> The standard choice is c++ 
>> 
>> [eschnigma@manjaro ~]$ c++ --version 
>> c++ (GCC) 6.1.1 20160501 
>> Copyright (C) 2016 Free Software Foundation, Inc. 
>> This is free software; see the source for copying conditions. There is NO 
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> 
>> But I've tried enforcing g++ as such: 
>> 
>> -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc 
>> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++ 
>> 
>> And that has the same results. 
>> 
>> Version: 
>> 
>> [eschnigma@manjaro ~]$ g++ --version 
>> g++ (GCC) 6.1.1 20160501 
>> Copyright (C) 2016 Free Software Foundation, Inc. 
>> This is free software; see the source for copying conditions. There is NO 
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> 
>> On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote: 
>> 
>> [eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug" 
>> -- The C compiler identification is unknown 
>> -- The CXX compiler identification is unknown 
>> 
>> This is definitely the reason for no debug symbols. If the compiler is 
>> unknown then CMake won't know the right flags to pass to generate debug 
>> info. The more important question though is why the compiler can't be 
>> identified. What compiler is being used? Can check with /usr/bin/c++ 
>> --version ?
 

Links:
--
[1] https://archive.archlinux.org/packages/l/
-- 

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] CPack with BZIP2 is a lot slower than GNU tar

2016-06-02 Thread Alessio
I'm comparing the following two things:
  1. cpack TBZ2 generator
  2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression)

I cannot avoid CPack. It takes care of way too many little details of the
packaging. Obviously we use it via lots of install() statements in our
CMakeLists.txt files.

On 2 June 2016 at 06:14, Raymond Wan  wrote:

> Hi,
>
>
> On Wed, Jun 1, 2016 at 8:26 PM, Alessio 
> wrote:
> > Is anyone else having problems with the speed of cpack?
> >
> > Out of one of our code bases we produce two packages on Linux using the
> > BZIP2 generator with CMake 3.4.0. I provide a few stats on the packages
> > below. They are not particularly fat. GNU tar will take ~1min to tar the
> > biggest one up with the same compression tech.
> >
> > CPack takes a good 4~5min for each of them.
>
>
> I have to admit that I'm not a cpack user.  So, I'm not sure if I can help.
>
> But are you comparing:
>
> "cmake + bzip" versus "cmake + tar"?
>
> By default tar doesn't do any compression.  It concatenates all of the
> files together.  That might be why it is so fast.  Perhaps you can
> remove cmake from the equation and compare bzip with tar?  I *guess*
> the speed difference might be the same and perhaps unrelated to cmake.
> (Just my guess, of course.)
>
> On the other hand, if speed is an issue, consider using gzip.  It
> won't compress as well as bzip, but it should be faster in terms of
> compression time.
>
> Ray
>
-- 

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