Re: [CMake] How to specify Redhat Developer Toolset compiler?

2019-06-20 Thread Eric Noulard
I would bet that enabling the toolset before launching CMake will do the
trick.
Otherwise set CC and/or CXX env var to the desired path before launching
CMake.

Le jeu. 20 juin 2019 à 17:39, David Aldrich 
a écrit :

> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version
> x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
> project(hello_world LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
>   PRIVATE
> main.cpp
> Message.hpp
> Message.cpp)
>
> I also have Redhat Developer Toolset 7 installed which I can enable in my
> bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Why do executables link static libs that shared libs were built from?

2019-06-17 Thread Eric Noulard
Le lun. 17 juin 2019 à 02:01, Paul Smith  a écrit :

> On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> > Le dim. 16 juin 2019 à 18:26, Paul Smith  a
> > écrit :
> > > But, that's not the only way to use shared libraries.  I'm trying
> > > to collect a number of static libraries with different interfaces
> > > into a single shared library that can be linked with executables.
> >
> > Correct me if I'm wrong but I guess that if your goal is to "collect"
> > all those static libs *into* a shared lib then what you need is to
> > make your STATIC libs,  OBJECT libs and then I think you'll get what
> > you expect.
>
> Yep, I'm familiar with OBJECT libs and if I could use them they would
> give the correct behavior, you're right.  Unfortunately it's not the
> case that OBJECT libraries are completely "drop-in" replaceable for
> STATIC libraries, and they cannot be substituted in my environment.
>
> See, for one example:
> https://gitlab.kitware.com/cmake/cmake/issues/19388
>
> I am not able to rework my system comprehensively enough to remove all
> mutual references between all my current libraries.  And there are
> other issues where OBJECT libraries aren't the equivalent of STATIC
> libraries.
>

Yes right.


> > Otherwise (at least in the way CMake currently works) any symbols
> > defined in foo.a STATIC lib will *stay* in it. So in the end when you
> > link an executable using bar.so SHARED lib only (which is using
> > foo.a) then you won't have the symbol you need from foo unless foo.a
> > is added to the link line ? Am I right?
>
> No, that's not right.
>
> The visibility of symbols depends on how your code is compiled and has
> nothing to do with cmake and whether cmake links into a shared or
> static library.
>
> On POSIX systems (gcc and clang), all symbols are public by default
> regardless of whether you are compiling them for a static or shared
> library.
>
> On Windows it's all more complicated, but in my situation I've added
> the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.
>

Yes you are right and I know that, but AFAIK when (with CMake) you TLL a
shared lib to a static lib. You do not end up with any of the static lib
symbol in the shared lib.
At least none of them are visible with nm. (I did only test that on Linux).

> But how can you do that without either:
> >
> > 1) adding the static lib to any link line (including the one using bar)
> > 2) *merging* foo.a *into* bar.so which should be what you achieve by
> > making foo an OBJECT lib.
>
> I'm not sure what you mean by "merging foo.a into bar.so": you can't
> merge something into a shared library any more than you can merge
> something into an executable.  By putting "foo" into the TLL of "bar",
> I've added the static library to the creation of the shared library:
>
>   cc -shared -o bar.so bar.o libfoo.a
>
> Now when bar.so is created it will have the required contents of
> libfoo.a in it.
>

You mean that the part of libfoo.a which is actually used by some part of
bar.o gets in bar.so
or any [exported] symbol found in libfoo.a gets in bar.so with the same
export rule?

My test showed me something different but I'll check again, I must have
done something wrong.


> > If we can agree on that, then using the current rules of CMake
> > > inheritance this implies that we can NEVER add a static library as
> > > a PUBLIC TLL for a shared library.
> >
> > Exactly my point. I understand what you say, but if ever CMake was
> > doing that you simply couldn't switch (GLOBALLY) from SHARED to
> > STATIC using
> > https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> > is a single SHARED lib was explicitely specified.
>
> I wasn't familiar with that option, but I don't think it makes a
> difference whether the libraries are made SHARED via this option or
> whether they are made SHARED via direct specification: the behavior is
> the same.
>
> > My opinion is that CMake may handle TLL(SHARED STATIC) differently
> > than TLL(SHARED SHARED) but forbidding the first would be a major
> > headache when you want to go from STATIC to SHARED lib one step after
> > another (I have a concrete example in mind in a legacy project).
>
> I didn't say it should be forbidden!!
>
> I said that as cmake is currently implemented it doesn't make sense to
> do it, implying that cmake might want to change its behavior in this
> area to be more useful.
>

OK now I get your point, thank you for clarifying.


> However, after more investigation I see that I was wrong about how
> linkers resolve symbols at least in POSIX

Re: [CMake] Why do executables link static libs that shared libs were built from?

2019-06-16 Thread Eric Noulard
Le dim. 16 juin 2019 à 18:26, Paul Smith  a écrit :

> Let me just mention up-front that I spent about 2 weeks earlier this
> year completely converting our circa-2011 cmake environment to ultra-
> modern cmake: switching completely to TLL, interfaces, removing
> virtually all if-statements and converting them into generator
> expressions, etc.  So I'm very familiar with CMake's model for PRIVATE,
> PUBLIC, and INTERFACE and how inheritance works.
>
> And, I see the paradigm you're operating under where a shared library
> provides a single "interface" that is public.
>
> But, that's not the only way to use shared libraries.  I'm trying to
> collect a number of static libraries with different interfaces into a
> single shared library that can be linked with executables (in my case I
> have 220 unit test programs which, when linked statically, not only
> take a very long time and a lot of memory, but use about 45G of disk
> space per build--I am collecting these into a shared library that can
> be linked with our unit tests.  In my testing this reduces the size of
> a sample unit test executable from 400M down to about 8M).
>

Correct me if I'm wrong but I guess that if your goal is to "collect" all
those static libs *into* a shared
lib then what you need is to make your STATIC libs,  OBJECT libs and then I
think you'll get what you expect.
I.e. in your CMakeLists.txt
replace
add_library(foo STATIC foo.c)
with
add_library(foo OBJECT foo.c)

Otherwise (at least in the way CMake currently works) any symbols defined
in foo.a STATIC lib will *stay* in it. So in the end when you link an
executable
using bar.so SHARED lib only (which is using foo.a) then you won't have the
symbol
you need from foo unless foo.a is added to the link line ? Am I right ?


> So: I need my shared library to export a combination of ALL the public
> interfaces of the static libraries it was built from, but not,
> obviously, export the static libraries themselves.
>

But how can you do that without either:

1) adding the static lib to any link line (including the one using bar)
2) *merging* foo.a *into* bar.so which should be what you achieve by
making foo an OBJECT lib.



> On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote:
> > The behaviour is correct according to what you are telling CMake to
> > do. If you use PUBLC in a target_link_libraries() call, you are
> > saying that anything that links to your shared library should also
> > link to the static library.
>
> That simply does not make sense, from the point of view of how a
> program and a linker work (I understand it's how CMake works).
>
> Let me work backwards, starting with a fact that hopefully we can all
> agree on:
>
>It is NEVER appropriate to put a static library into the
>INTERFACE_LINK_LIBRARIES of a shared library.
>
> I'd be interested to hear counter-arguments, but even if there are any
> reasons for it my position is that in those very rare cases you should
> be listing the static library in the TLL of the executable directly.
>

Correct me if I'm wrong but you are saying that TLL(bar.so foo.a)  should
merge foo.a into bar.so ?
But TLL(myexe foo.a) should add foo.a in the link line of myexe?


> If we can agree on that, then using the current rules of CMake
> inheritance this implies that we can NEVER add a static library as a
> PUBLIC TLL for a shared library.
>

Exactly my point. I understand what you say, but if ever CMake was doing
that
you simply couldn't switch (GLOBALLY) from SHARED to STATIC
using https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
is a single SHARED lib was explicitely specified.

My opinion is that CMake may handle TLL(SHARED STATIC) differently than
TLL(SHARED SHARED) but forbidding the first would be a major headache when
you want to go from STATIC to SHARED lib one step after another (I have a
concrete
example in mind in a legacy project).

Even if I agree that this is a very bad idea
"to put a static library into the INTERFACE_LINK_LIBRARIES of a shared
library"

it currently works with CMake a may be saving a lot of time to many people
switching
gradually from a legacy build system doing just that.


> Which seems, to me, quite ridiculous because why shouldn't you want to
> allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and
> INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by
> the shared library into its PUBLIC interface?  That seems like a quite
> reasonable thing to want to do.
>

I don't follow, it seems to be that case when the shared lib TLL publicly
to the static lib?
I really think think the behavior you are expecting already works if you
replace your static lib with object lib.
https://cmake.org/cmake/help/v3.14/command/target_link_libraries.html#linking-object-libraries

But may be I missed something?

-- 
Eric
-- 

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 

Re: [CMake] Individualized compile_commands.json per executable target?

2019-06-11 Thread Eric Noulard
Le mar. 11 juin 2019 à 05:16, Staley, Martin Frank via CMake <
cmake@cmake.org> a écrit :

> I'm using the Clang/LLMV APIs to build a code analysis tool that gives my
> users some additional analysis of their C++ codes, above and beyond what
> the compiler, proper, provides.
>
> With a set(CMAKE_EXPORT_COMPILE_COMMANDS ON) in CMakeLists.txt, cmake
> emits a "compilation database" file, compile_commands.json, that contains
> exact compilation commands for all relevant source files. The .json can be
> consumed by my analysis tool to get what it needs. Except
>
> Here's the problem. (And I've tried various googles, but nothing panned
> out.) compile_commands.json contains data for *all* source files involved
> in *any* executable for which cmake emits Makefile rules. My analysis tool
> needs input that reflects those (and only those) source files that are
> involved in any *one* of the (generally more than one) executables.
>
> EXAMPLE. Say I have some general C++ constructs in a.cc, b.cc, and c.cc,
> and two C++ executables (roughly speaking, with a main()): foo.cc and
> bar.cc. Assume further that, linkage-wise, foo.cc needs the material from
> a.cc and b.cc (but not c.cc), while bar.cc needs the material from b.cc and
> c.cc (but not a.cc). These dependencies are of course programmed into a
> CMakeLists.txt.
>
> In this situation, cmake will emit a compile_commands.json that has
> commands for all five sources: {a.cc, b.cc, c.cc, foo.cc, bar.cc}. But my
> analysis tool, run thereon, doesn't know how to divvy up the various
> elements, and it ends up reporting, among other things, the moral
> equivalent of multiply-defined symbol errors.
>
> Ideally, I'd love to have a way that Cmake could emit, say, foo.json
> containing only the compile commands for {a.cc, b.cc, foo.cc}, and a
> bar.json containing only the commands for {b.cc, c.cc, bar.cc}. Basically,
> individualized compilation databases for each executable target.
>
> There are, of course, alternatives. Given additional input, my tool could
> pull (only) the proper entries from the current, aggregated
> compile_commands.json. Or, post-cmake, I could allow for a dry-run verbose
> make of a single executable, and parse out the requisite information. For
> users, however, and for simplicity's sake, I'm hoping for something more
> direct. CMake has what I need, in some form - it must, in order to create
> the Makefile! So, life would be absolutely fabulous if this existing
> knowledge could be used to create executable-specific .json databases as
> outlined above.
>

> Is this in fact available, and my googling skills aren't up to par?
>

This is not exactly what you are looking for but you may certainly use the
CMake file-api:
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html#manual:cmake-file-api(7)
in order to get what you want (namelly the list of files for a given target)

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Conditional install() rules based on CPack generator

2019-06-05 Thread Eric Noulard
Le mer. 5 juin 2019 à 12:00, Mathieu Malaterre 
a écrit :

> Hi there,
>
> I am trying to use NuGet generator for GDCM project. Typically my
> install rules are as follow:
>
> add_library(foo SHARED foo.c)
> install(TARGETS foo
>   EXPORT ${MY_TARGETS_NAME}
>   RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
>   LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
>   INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
>   ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
> )
>
> where:
>
> MY_INSTALL_BIN_DIR='bin'
> MY_INSTALL_LIB_DIR='lib'
> MY_INSTALL_INCLUDE_DIR='include'
>
> this works quite nicely for basic 'make install', as well as binary
> zip or NSIS installer.
> However this directory layout does not seems to be compatible with
> Windows RIDs[*]. For example my native *.dll files would need to be
> moved from the 'bin' directory to something like 'lib/win7-x64'.
>
> How can I handle conditional install() rules based on CPack generator
> (NuGet in my case) ?
>

I'm not sure you can.
install() rules are processed when CMake runs and generate all
cmake_install.cmake files.
then when CPack runs it triggers the install using the files generated at
CMake time.

So while you can achieve some conditional actions when CPack runs using
CPack project config file
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE

AFAIK you cannot (re)write install rule because they have already been
processed.

What you could do (as a workaround) in your CMakeLists.txt is to define
both WinXX specific CPack components
and your "generic" CPack components that can be used as a default.
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
  LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
  INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
)
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_WINXX_INSTALL_BIN_DIR} COMPONENT
Applications-Winxx
  LIBRARY DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT Libraries-Winxx
  INCLUDES DESTINATION ${MY_WINXX_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT DebugDevel-Winxx
)

i.e. install the same thing twice in two places.
and then at CPack time (when CPack runs) code some logic in your CPack
Config file in order
to set  CPACK_COMPONENTS_ALL to appropriate value depending on the value of
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_GENERATOR

something like
if ("${CPACK_GENERATOR}" STREQUAL "NuGet")
   set(CPACK_COMPONENTS_ALL
"Applications-Winxx;Libraries-Winxx;DebugDevel-Winxx")
else()
set(CPACK_COMPONENTS_ALL "Applications;Libraries;DebugDevel")
endif()

that way CPack depending on the generator will ship either "WinXX"
component or "generic" ones.

I think (not tested) it should work but this is clearly a workaround.


Eric



> Thanks,
>
> [*] https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
>
> --
> Mathieu
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Dependency cycle - why?

2019-05-25 Thread Eric Noulard via CMake
Le sam. 25 mai 2019 à 13:51, Bill Somerville  a
écrit :

> Hi Robert,
>
> thanks for that, the target name change does seem to help but I am still
> unable to achieve my goal. Here is a simplified example that demonstrates
> the problem:
>
> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
> project (demo LANGUAGES NONE)
> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch 
> prog${CMAKE_EXECUTABLE_SUFFIX})
> add_executable (prog IMPORTED)
> add_dependencies (prog prog_target)
> set_target_properties (prog PROPERTIES IMPORTED_LOCATION 
> ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
> install (TARGETS prog RUNTIME DESTINATION bin)
>
> which gives the following error at CMake configuration:
>
> CMake Error at CMakeLists.txt:7 (install):
>   install TARGETS given target "prog" which does not exist.
>
>
> -- Configuring incomplete, errors occurred!
>
> So the target that 'add_executable(name IMPORTED)' creates is not a real
> executable target. I can change its properties but the 'install(TARGETS
> ...)' command thinks it does not exist. Note that a executable target is a
> very simple demonstration and I understand that I can use 'install(PROGRAM
> ...)' just about as easily, but when it comes to a shared library it gets a
> lot more complex when using, exporting, and instlling it, and it seems that
> IMPORTED targets fall well short of useful when they are actually produced
> by the current CMake project.
>
> I can understand that an IMPORTED target is perhaps not meant to be
> installable
>

Robert will give his advice on that but I bet IMPORTED target were never
meant to be drop-in *replacement* of genuine target.

They were meant to ease *reference to* object/lib:executable that are
outside the build of the project.
e.g the doc says:
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside the
project"

Nmelly a target that is "already installed somewhere" and that you want to
reference in your CMake build.


> but if so then your statement that "The goal that you have is fully
> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
> foreign tools to make binary targets and wish to have CMake treat them *as
> if* they were created by supported languages like C, ++, or Fortran. Am I
> still missing something?
>

My opinion is that IMPORTED target are not designed (as of today) for that
purpose.

When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
see:
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
and may be: https://github.com/aadidenko/golang-cmake-example (or fork
of this)

2) define a set of custom macros that mimic genuine target behaviour.
may be see: https://github.com/cpconduce/go_cmake

If you want to have a look at existing similar example shippped with CMake,
have a look at UseJava.cmake module (
https://cmake.org/cmake/help/latest/module/UseJava.html)
You'll see that you have
add_jar, which is similar to add_executable and create a custom target
and
install_jar which is similar to install on genuine target but plays with
target properties and install(FILES...) in order to mimic that.
see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake

I'm not developing with golang but AFAIK go has a builtin "build system" so
bringing go as a language in CMake may not be the best option,
but again I am no Go expert.

The only reference of that kind of thing I found in the CMake mailing list
is oldish:
https://cmake.org/pipermail/cmake-developers/2011-August/013715.html

May be adding the support for "install" command for IMPORTED target is
doable but this seems to be a feature request to be discussed on developer
mailing list;
Regards,
Eric


> Regards
> Bill Somerville.
>
> On 24/05/2019 20:23, Robert Maynard wrote:
>
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this 
> tohttps://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville  
>  wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file 

Re: [CMake] cmake doesn't run all tests

2019-05-21 Thread Eric Noulard
Le mar. 21 mai 2019 à 11:45, hex  a écrit :

> hello,
>
> I have two modules in my CMake project:
>
> *root*
> *├── foo*
> *│   ├── CMakeLists.txt*
> *│   ├── src*
> *│   │   └── foo.c*
> *│   └── tests*
> *│   ├── foo_unit_test.c*
> *│   └── CMakeLists.txt*
> *├── CMakeLists.txt*
> *└── moo*
> *├── CMakeLists.txt*
> *├── src*
> *│   └── moo.c*
> *└── tests*
> *├── CMakeLists.txt*
> *└── moo_unit_test.c*
>
> my root project has:
>
> *enable_testing()*
>
> *add_subdirectory(adder)*
> *add_subdirectory(viterbi_encoder)*
>
>
> and each module has:
>
> *add_subdirectory(tests)*
>
>
> For the tests I am using add_test() and make all test.
>
> yet, this only runs the tests within the first add_subdirectory. Other
> modules are ignored.
>
> Do the CMakeLists.txt in the sub-directory have their own project command
or is your main top-level CMakeLists.txt the only CMakeLists.txt with
project  command ?

How can I run all tests at once?
>
> How do yu run the tests?

make tests ?
ninja tests ?
ctest ?

What does
$ ctest -N
says?

This should work at least it "works-for-me" so there must be some
difference between the CMakeLists.txt in the directory that works and in
the directory that does not.
Do you have a sample setup which exhibit the issue that you can share?


Thank you in advance.
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

2019-03-28 Thread Eric Noulard
Le ven. 22 mars 2019 à 18:30, Stewart, Robert  a
écrit :

> Have a look at the code I quoted from CPackRPM.cmake:
>
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>
> If CPACK_RPM_USER_BINARY_SPECFILE is defined, then RPMBUILD_FLAGS is *not*
> set to -bb.
>

Sorry I missed your last answer.
My link to up-to-date code:
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658

shows that "-bb" is always set.

This was fixed some time ago:
https://gitlab.kitware.com/cmake/cmake/commit/574c81e28cef6737adc1619ce3b44b43bdcf308b
CMake 3.8.0 and after should include this fix.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

2019-03-22 Thread Eric Noulard
Le mer. 6 mars 2019 à 21:33, Stewart, Robert  a
écrit :

> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on
> different platforms).  In so doing, our CMake invocation of CPack to create
> RPMs now fails and I'm hoping someone can help.  I have a spec file and I
> want to run rpmbuild -bb, but I can't figure out how to do it.
>
>

>
> The result is that my attempt to port to the all-variable approach failed,
> so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as
> before.  Unfortunately, when I do so, CPackRPM.cmake doesn't set
> RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful.  The issue
> is in the following code:
>
> # We should generate a USER spec file template:
> #  - either because the user asked for it :
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> #  - or the user did not provide one : NOT
> CPACK_RPM_USER_BINARY_SPECFILE
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>


I missed that. Do you mean that even though you
set(CPACK_RPM_USER_BINARY_SPECFILE /)

CPackRPM does not process the spec file with rpmbuild -bb ?

AFAIU from the source:

"-bb" flags are always setup when binary RPM is built.
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658

I am confused. Could restate the problem.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

2019-03-22 Thread Eric Noulard
Le mer. 6 mars 2019 à 21:33, Stewart, Robert  a
écrit :

> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on
> different platforms).  In so doing, our CMake invocation of CPack to create
> RPMs now fails and I'm hoping someone can help.  I have a spec file and I
> want to run rpmbuild -bb, but I can't figure out how to do it.
>
> We have been using a custom spec file all along, but I found information
> indicating that doing so is (now?) considered a hack and that everything
> should be possible merely by setting CPACK_* variables.  Unfortunately,
> that's not the case.


Which CPACK_xxx variables did you use?
CPACK_RPM_SPEC_MORE_DEFINE ?
CPACK_RPM_USER_FILELIST ?



> With the following %files entries, CPackRPM.cmake chokes:
>
> %defattr(-, %{user}, %{group}, 0755)
> %dir %{destination}
> %dir %{versioned}
> %dir %{foo}
> %{foo}/*.sh
> %attr(555, %{user}, %{group}) %{foo}/a
> %dir %{bar}
> %attr(544, %{user}, %{group}) %{bar}/b
> %attr(444, %{user}, %{group}) %{bar}/*common
> %{bar}/lib
>
> The result is that my attempt to port to the all-variable approach failed,
> so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as
> before.  Unfortunately, when I do so, CPackRPM.cmake doesn't set
> RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful.  The issue
> is in the following code:
>
> # We should generate a USER spec file template:
> #  - either because the user asked for it :
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> #  - or the user did not provide one : NOT
> CPACK_RPM_USER_BINARY_SPECFILE
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>
> I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I
> include CPack, but that isn't propagated to CPackRPM.cmake.  I tried adding
> a custom target that invoked "${CMAKE_CPACK_COMMAND} -D
> RPMBUILD_FLAGS=-bb", but that didn't work either.
>

You cannot add flags meant to be used at CPack time in your CMakeLists.txt
because CMakeLists.txt is read when *cmake* runs not when *cpack* runs.
See:
https://github.com/dev-cafe/cmake-cookbook/tree/master/figures/cmake-times
for the description of various times

However you can use
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for that purpose.
If you specify (in your CMakeLists.txt) the name of a file as
set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_BINARY}/mycpack_config.cmake)
then the 'mycpack_config.cmake' will be processed by CPack when it runs.
You can find an example usage here:
http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt#n621
in this case the CERTICPackOptions.cmake.in  (in the source tree) is first
configure to CERTICPackOptions.cmake (in the build tree)
then
SET(CPACK_PROJECT_CONFIG_FILE "${CERTI_BINARY_DIR}/CERTICPackOptions.cmake")

indicate that CPack should use it at "CPack-time".

The process describing how "CPACK_PROJECT_CONFIG_FILE" is used is described
at the beginning of : https://cmake.org/cmake/help/v3.12/module/CPack.html

If the regex processing of the %files content were more robust, I wouldn't
> trip over the RPMBUILD_FLAGS issue,


Then may be you can file a patch for making those more robust?


> but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and
> since it is currently, it should be possible for me to set RPMBUILD_FLAGS.
>
> Ideas?


1) Use   CPACK_RPM_USER_BINARY_SPECFILE and CPACK_PROJECT_CONFIG_FILE.
2) propose a patch for

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


[cmake-developers] cmake server to cmake file api swicth

2019-03-21 Thread Eric Noulard
Hi there,

I saw that CMake was apparently switching from CMake server mode (
https://cmake.org/cmake/help/v3.14/manual/cmake-server.7.html) to file api (
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html).

I first saw it in CMake 3.14 rc and final announce:
https://cmake.org/pipermail/cmake/2019-March/069155.html

However I didn't see much discussion about that on either developer or user
ML beside recent statement from Brad
https://cmake.org/pipermail/cmake-developers/2019-March/031129.html
telling that server mode will certainly be deprecated in favor of file api.

Can any CMake developer that has been participating in this new file api
shed some light on the rational of this foreseen switch?
I'm just curious about it. What was wrong/problematic with server mode?
Does the new file api solves some IDE integration issue?

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] Troubles with include_directories

2019-03-10 Thread Eric Noulard
Le sam. 9 mars 2019 à 08:44, workbe...@gmx.at  a écrit :

> Hi everyone,
>
> i've a project setup that looks like this:
>
>
> abc.h
>
> def.h
>
> and all my other .cpp and .h files are in the folder intern. Now my
> CMakeLists.txt looks like this:
>
> cmake_minimum_required(VERSION 3.7)
> project(BS_Application)
> set(SRC
>  BS_AppTypes.hpp
>  BS_IEvent.hpp
>  BS_ISystem.hpp
>  BS_IWindow.hpp
>  BS_ITimerTask.hpp
>  BS_IEventConsumer.hpp
>  BS_Application.cpp
>  BS_Button.cpp
>  BS_ContextSDL.cpp
>  BS_ISystem.cpp
>  BS_System.cpp
>  BS_SystemSDL.cpp
>  BS_WindowSDL.cpp
>  BS_ContextSDL.cpp
>  BS_DisplayManagerSDL.cpp
>  BS_Button.cpp
>  BS_EventManager.cpp
>  BS_EventPrinter.cpp
>  BS_ModifierKeys.cpp
>  BS_DisplayManager.cpp
> )
> set(INC
>  intern
> )
> include_directories(${INC})
> add_library(BS_Application STATIC ${SRC})
>
> Where all files above BS_Application.cpp are in the folder intern but he
> is not able to find BS_Application.cpp but i added it to the
> include_direcotires, what am i doing wrong here ?
>

First of all usage of include_directories is a discouraged old-style
variable oriented CMake.
You should prefer target oriented rule.
Namelly target_include_directories().
You can have a look at:
https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ and/or
refered presentation from Daniel Pfeifer or Mathieu Ropert there in.
It'll get you a broad view of the "Modern CMake way to go".

Now both commands (target_include_directories or include_directories)
influence where *header* file are found.
So that if you say

include_directories(${INC})
add_library(BS_Application STATIC BS_Application.cpp)

CMake won't go looking for "BS_Application.cpp" inside ${INC}.
You should refer to your source files with the proper path:
i.e.
add_library(BS_Application STATIC ${INC}/BS_Application.cpp)

You may consider having a look at how to use target_source as well.
Craig Scott published a nice blog entry about that:
https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/

Regards,
Eric


> best regards!
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Remove folders created by install

2019-02-20 Thread Eric Noulard
There are some possible solutions and reference here:
https://stackoverflow.com/questions/41471620/cmake-support-make-uninstall

Le sam. 16 févr. 2019 à 15:48, Felix Crazzolara 
a écrit :

> Hi everyone
>
> For my smaller projects I'd like to have 'uninstall' functionality. To
> remove installed files I can call:
>
> xargs rm < build/install_manifest.txt
>
> Unfortunately this won't delete any folders generated by the
> installation. Is there a different file that keeps track of the created
> directories, or what is the recommended way to implement such
> functionality?
>
> Example:
> Suppose that I install _some_header.hpp in
> /include// using the command install(TARGETS
>  EXPORT -targets ARCHIVE DESTINATION lib
> PUBLIC_HEADER DESTINATION include/) then I want not only
> to remove
> /include//_some_header.hpp, but also
> the directory /include//.
>
> Cheers,
>
> Felix Crazzolara
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] requiring parallel building but sequential linking

2019-02-17 Thread Eric Noulard
Le lun. 18 févr. 2019 à 00:01, Craig Scott  a
écrit :

>
>
> On Mon, Feb 18, 2019 at 9:35 AM Domen Vrankar 
> wrote:
>
>> Hi,
>>
>> I'm building llvm project with CMake.
>> While build process is compiling the code I prefer running "make -j3" on
>> my 4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB
>> of ram - part of it is system and not build related).
>> While build process is linking I must run "make" with a single job
>> because otherwise I run out of memory (cores do little work but ram usage
>> goes past 23 GB).
>>
>> Currently I'm handling this so that I first run "make -j3" and once I get
>> to about 90% (first larger linking) I hit ctrl+c and run "make".
>>
>> Is there a feature in CMake that would support handling this transition
>> of parallel builds, sequential linking out of the box?
>> (while I'm mostly interested in Linux/make support, having the same
>> feature for Windows/nmake/ninja through the same command line cmake command
>> would be even better)
>>
>
> This is available for Ninja with the JOB_POOL_LINK
>  target
> property, the default for which can be set project-wide with the
> CMAKE_JOB_POOL_LINK
>  
> variable.
> You can control the number of parallel jobs for a given pool with the
> JOB_POOLS  global
> property.
>

I use that a lot and I shall add that, on my side, link jobs memory
consumption heavily depends on the type of build (debug, release,
profiling, etc...), moreover
the available memory amount vary a lot as well whether if the build occurs
on a "local" developer desktop or on some CI runner.
So we end up doing some very basic CMake computation in order to
automatically adapt to the local resource.
Nothing fancy but it has been proven very useful for us:

if (CMAKE_BUILD_TYPE STREQUAL "Debug")
   cmake_host_system_information(RESULT MYMEM QUERY TOTAL_PHYSICAL_MEMORY)
   # Compute the number of authorized number of link jobs by:
   #   - "saving" 4 GiB of memory
   #   - assume each debug link job may consume 2GiB
   math(EXPR NLJ "(${MYMEM}-4096)/2048")
   set_property(GLOBAL PROPERTY JOB_POOLS link_jobs=${NLJ})
   set(CMAKE_JOB_POOL_LINK link_jobs)
elseif (CMAKE_BUILD_TYPE STREQUAL "Release")
...
endif()

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Eric Noulard
Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona  a
écrit :

> The problem is it is very likely that there are some circular dependencies
> in the build tree -- which is why it was broken up to generation of all,
> then build all, then link all in the first place.
>

Yes, wrong solution to a real design issue :-)


>
> With circular dependencies there's no real way to sort these dependencies
> out without just running generation twice, but the first run will get a
> bunch of errors for missing packages.
>

I understand the situation, I did face that too in the past.
If there is not too much circular deps you may either break them by writing
(by hand) a bunch of imported target or you can merge in the same CMake
project the sub-projects belonging to the same cycle.
Feasibility depends on the amount of projects (and cycle) you have.




>
> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard 
> wrote:
>
>>
>>
>> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  a
>> écrit :
>>
>>> I have a collection of interdependent CMake projects (lots of legacy
>>> code) that I want to convert to using CMake targets for linking. The code
>>> is built in such a way that all projects run cmake generation, then all
>>> projects build, then all projects link.
>>>
>>> I would like to export a CMake target from one of the projects and link
>>> to it in another, but the issue is the project I am exporting from runs its
>>> cmake generation AFTER the project I am linking the target in. This causes
>>> "find_package" to fail because the target has not been exported yet, but
>>> realistically the exported target is not needed until link-time.
>>>
>>
>> This heavily depends on the target. Modern CMake target convey compile
>> time information as well like compile flags, include directory etc...
>>
>> Can't you re-order the cmake generation order of your projects?
>> If you [ever] have the graph dependency of your projects you may
>> topologically sort them in order to avoid this issue and superbuild them in
>> appropriate order.
>>
>>
>>> Is there a way to delay "find_package" to not look for the package until
>>> link-time?
>>>
>>
>> I don't think so.
>>
>>
>>> At link-time the package will have been exported already and if
>>> "find_package" was not called until then, it would be found successfully
>>> and the target could be pulled in and linked to.
>>>
>>
>> But the build compile line options used to generate build system files
>> are computed during CMake configuration/generation step.
>> So I don't think what you ask is possible.
>>
>> --
>> Eric
>>
>

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Eric Noulard
Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  a
écrit :

> I have a collection of interdependent CMake projects (lots of legacy code)
> that I want to convert to using CMake targets for linking. The code is
> built in such a way that all projects run cmake generation, then all
> projects build, then all projects link.
>
> I would like to export a CMake target from one of the projects and link to
> it in another, but the issue is the project I am exporting from runs its
> cmake generation AFTER the project I am linking the target in. This causes
> "find_package" to fail because the target has not been exported yet, but
> realistically the exported target is not needed until link-time.
>

This heavily depends on the target. Modern CMake target convey compile time
information as well like compile flags, include directory etc...

Can't you re-order the cmake generation order of your projects?
If you [ever] have the graph dependency of your projects you may
topologically sort them in order to avoid this issue and superbuild them in
appropriate order.


> Is there a way to delay "find_package" to not look for the package until
> link-time?
>

I don't think so.


> At link-time the package will have been exported already and if
> "find_package" was not called until then, it would be found successfully
> and the target could be pulled in and linked to.
>

But the build compile line options used to generate build system files are
computed during CMake configuration/generation step.
So I don't think what you ask is possible.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Help with non-standard use of CMake

2019-01-02 Thread Eric Noulard
Hi Kyle & Donald,

ctest scripting is documented in here as well:
https://cmake.org/cmake/help/v3.13/manual/ctest.1.html#ctest-script

Since this is generated from in-source documentation:
https://github.com/Kitware/CMake/blob/master/Help/manual/ctest.1.rst

may be an explanation on how to use ctest without cmake directly in a
subsection of this manual would be  a way to keep it
more up-to-date along with the source.


Le mer. 2 janv. 2019 à 18:26, Kyle Edwards via CMake  a
écrit :

> On Wed, 2019-01-02 at 12:01 -0500, Donald MacQueen [|] wrote:
> > I looked at the example of Using ctest and cdash without cmake
> > (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTE
> > ST-and-CDASH-without-CMAKE#steercmake)
> > and I think I will try to go in that direction.
>
> Donald,
>
> I just looked at that page, and it looks like it was written a very
> long time ago, before cmake_host_system_information() and
> execute_process() were created. The exec_program() command has been
> deprecated for years. I'm going to work on updating it a little bit
> right now.
>
> Kyle
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-17 Thread Eric Noulard
Le lun. 17 déc. 2018 à 22:04, Eric Noulard  a
écrit :

> Hi Kyle,
>
> Is your proposal a follow-up on the initial bunch of ideas launched in
> this thread launch by Eike in November
> https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
> with follow-up ideas in in december:
> https://cmake.org/pipermail/cmake-developers/2018-December/030920.html
>
> or is it somehow unrelated?
>
>
> Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
> cmake-developers@cmake.org> a écrit :
>
>> Hello everyone,
>>
>> One of the things that's long been requested of CMake is the ability to
>> have multiple toolchains - for instance, one host toolchain and one
>> cross toolchain, so that "utilities" needed for build can be built with
>> the host toolchain and then the "real" software can be built with the
>> cross toolchain.
>>
>> To solve this problem, I would like to propose the creation of a new
>> first-class object type, the "toolchain" type, which would replace the
>> current variable-based system, similar to how imported targets replaced
>> variable-based usage requirements.
>>
>> Every project would automatically receive one toolchain, the "DEFAULT"
>> toolchain, which would be either automatically configured or configured
>> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
>> toolchains could be added with the add_toolchain() command:
>>
>> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>>
>
> This has some common design issue as my proposal:
> enable_cross_target(...)
> for which Eike has valuable doubt:
> https://cmake.org/pipermail/cmake-developers/2018-November/030919.html
>
>
>> Then, executables and libraries could have a toolchain specified:
>>
>> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Note that the TOOLCHAIN argument is optional, and if omitted, the
>> DEFAULT toolchain is used.
>>
>
> So if you want to build both for host and cross toolchain you'll have to
> explicitely
> add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
>
> If you follow the previously referred discussion you cannot assume that
> one lib/exe
> built for a toolchain is not built for another toolchain as well.
>
> How do you envision the cross-toolchain target dependency which was
> a question raised several time.
>
>
>> If a project uses multiple toolchains, we could have the option to
>> rename the default toolchain with an alternative add_toolchain()
>> syntax:
>>
>> add_toolchain(HostToolchain DEFAULT)
>>
>> Rather than adding a new toolchain, this would simply rename the
>> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
>> specification for each target could look like this:
>>
>> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Two new global read-only properties would be added: TOOLCHAINS and
>> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
>> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
>> the DEFAULT toolchain (which could be changed with the alternative
>> add_toolchain() syntax.)
>>
>> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
>> setting variables:
>>
>> set(CMAKE_C_COMPILER /usr/bin/gcc)
>> set(CMAKE_C_COMPILER_ID gnu)
>> # etc.
>>
>> it would instead set properties on the selected toolchain:
>>
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
>> /usr/bin/gcc)
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
>> C_COMPILER_ID gnu)
>> # etc.
>>
>
> I don't see why we should change the syntax of current toolchain file, I
> don't see the benefit.
> CMake already knows when (and which) toolchain file is loaded and it could
> perfectly automatically
>

... sorry wrong key pressed...

CMake could perfectly automatically create the new "TOOLCHAIN" object by
loading the very
same toolchain file as we have today. We could simple add a new variable
CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name
them as he wants.
When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-17 Thread Eric Noulard
Hi Kyle,

Is your proposal a follow-up on the initial bunch of ideas launched in this
thread launch by Eike in November
https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
with follow-up ideas in in december:
https://cmake.org/pipermail/cmake-developers/2018-December/030920.html

or is it somehow unrelated?


Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
cmake-developers@cmake.org> a écrit :

> Hello everyone,
>
> One of the things that's long been requested of CMake is the ability to
> have multiple toolchains - for instance, one host toolchain and one
> cross toolchain, so that "utilities" needed for build can be built with
> the host toolchain and then the "real" software can be built with the
> cross toolchain.
>
> To solve this problem, I would like to propose the creation of a new
> first-class object type, the "toolchain" type, which would replace the
> current variable-based system, similar to how imported targets replaced
> variable-based usage requirements.
>
> Every project would automatically receive one toolchain, the "DEFAULT"
> toolchain, which would be either automatically configured or configured
> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
> toolchains could be added with the add_toolchain() command:
>
> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>

This has some common design issue as my proposal:
enable_cross_target(...)
for which Eike has valuable doubt:
https://cmake.org/pipermail/cmake-developers/2018-November/030919.html


> Then, executables and libraries could have a toolchain specified:
>
> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Note that the TOOLCHAIN argument is optional, and if omitted, the
> DEFAULT toolchain is used.
>

So if you want to build both for host and cross toolchain you'll have to
explicitely
add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)

If you follow the previously referred discussion you cannot assume that one
lib/exe
built for a toolchain is not built for another toolchain as well.

How do you envision the cross-toolchain target dependency which was
a question raised several time.


> If a project uses multiple toolchains, we could have the option to
> rename the default toolchain with an alternative add_toolchain()
> syntax:
>
> add_toolchain(HostToolchain DEFAULT)
>
> Rather than adding a new toolchain, this would simply rename the
> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
> specification for each target could look like this:
>
> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Two new global read-only properties would be added: TOOLCHAINS and
> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
> the DEFAULT toolchain (which could be changed with the alternative
> add_toolchain() syntax.)
>
> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
> setting variables:
>
> set(CMAKE_C_COMPILER /usr/bin/gcc)
> set(CMAKE_C_COMPILER_ID gnu)
> # etc.
>
> it would instead set properties on the selected toolchain:
>
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
> /usr/bin/gcc)
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
> C_COMPILER_ID gnu)
> # etc.
>

I don't see why we should change the syntax of current toolchain file, I
don't see the benefit.
CMake already knows when (and which) toolchain file is loaded and it could
perfectly automatically


>
> where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
> file either at the root or by the add_toolchain() command.
>
> If you want to read the value of C_COMPILER, etc. then just use
> get_property():
>
> get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)
>
> Obviously this system would scale well to more than just two toolchains
> - just use as many add_toolchain() commands as you need.
>
> Backwards compatibility is going to be a challenge. Both the toolchain
> file and the project have to be aware of the new toolchain system,
> which means we have to handle four permutations:
>
> 1) old toolchain + old project
> 2) old toolchain + new project
> 3) new toolchain + old project
> 4) new toolchain + new project
>
> I propose adding a policy that both the toolchain file and the project
> can set separately, and which would have a slightly different meaning
> in each one. If the toolchain is OLD and the project is NEW, then the
> variables set by the toolchain file would be converted into properties
> on the toolchain for the project. If the toolchain is NEW and the
> project is OLD, then the properties on the toolchain would be converted
> into variables in the project. If both the toolchain and project have
> the same value, then no special 

Re: [CMake] Tracking progress of CMake TAR

2018-12-17 Thread Eric Noulard
Le lun. 17 déc. 2018 à 18:00, Person Withhats  a
écrit :

> I guess for now, anything that'll get it to work on Windows? That's the
> primary platform for this.
>

If you give up on portability then replace cmake -E tar with an external
program which has progress capability on Windows.
It looks like 7-zip can do that:
see: https://sevenzip.osdn.jp/chm/cmdline/switches/bs.htm
or: https://sourceforge.net/p/sevenzip/discussion/45797/thread/d10225f7/

I don't work on Windows those day so I won't be able to try it out.

Eric


>
> On Mon, Dec 17, 2018 at 8:53 AM Eric Noulard 
> wrote:
>
>>
>> Le lun. 17 déc. 2018 à 17:17, Person Withhats 
>> a écrit :
>>
>>> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
>>> files is going to help.
>>>
>>
>> Yes right.
>> You need some "size extraction progress" not number of files progress.
>>
>> I'm not sure classical un-archive program do have the feature.
>>
>> I'm pretty sure that "working progress bar" is most of the time very
>> difficult to implement:
>>
>> https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful
>>
>> I was hoping for some sort of progress bar or the like,
>>>
>>
>> I'm pretty sure cmake -E tar does not have this feature.
>> Genuine unix tar command does not have such feature and some people uses
>> 'pv' (http://www.ivarch.com/programs/pv.shtml)
>> for that very same purpose
>> e.g.
>> https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file
>>
>> I guess the issue is the same for other archive tool including zip:
>> https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress
>>
>> CMake is using libarchive for handling various archive files (including
>> tar) libarchive seems to have
>> some feature for progress display (
>> https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
>> but CMake code is not using it in any way.
>>
>>
>>> and yes I'm using cmake -E tar .-.
>>>
>>> Any ideas?
>>>
>>
>> Beside non-portable way no.
>>
>>
>>>
>>> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
>>> wrote:
>>>
>>>> I guess he is using
>>>>
>>>> cmake -E tar
>>>>
>>>> may be using 'v' verbose option from tar  should be enough.
>>>>
>>>> i.e.
>>>> cmake -E tar xvz your-archive.tar.gz
>>>>
>>>> It should display file names as they come out of the archive.
>>>> So unless your very big archive only contains relatively big files, the
>>>> output should evolve quite often.
>>>>
>>>> Eric
>>>>
>>>>
>>>> Le lun. 17 déc. 2018 à 15:46, Ian Cullen 
>>>> a écrit :
>>>>
>>>>> Are you calling tar via a custom command?  tar itself looks to have a
>>>>> few options to print progress:
>>>>>
>>>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>>>>>
>>>>> Although none of the options seem to know the archive's size, so
>>>>> aren't able to print a completion percentage.
>>>>>
>>>>>
>>>>> On 16/12/2018 21:31, Person Withhats wrote:
>>>>>
>>>>> When running tar via CMake (in order to use cross-platform
>>>>> work-ability and what not) it'd be great to have a progress bar of any
>>>>> sort.
>>>>>
>>>>> It's awkward to wait 30-60 minutes for file untarring with absolutely
>>>>> 0 information. I'm not aware of any way to do this through CMake directly,
>>>>> only alternative is e.g. python script that does the untar for me.
>>>>>
>>>>> Any suggestions? (sorry if this is reposted, can't remember if acc was
>>>>> approved before or after sending one time)
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> 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

Re: [CMake] Tracking progress of CMake TAR

2018-12-17 Thread Eric Noulard
Le lun. 17 déc. 2018 à 17:17, Person Withhats  a
écrit :

> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
> files is going to help.
>

Yes right.
You need some "size extraction progress" not number of files progress.

I'm not sure classical un-archive program do have the feature.

I'm pretty sure that "working progress bar" is most of the time very
difficult to implement:
https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful

I was hoping for some sort of progress bar or the like,
>

I'm pretty sure cmake -E tar does not have this feature.
Genuine unix tar command does not have such feature and some people uses
'pv' (http://www.ivarch.com/programs/pv.shtml)
for that very same purpose
e.g.
https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file

I guess the issue is the same for other archive tool including zip:
https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress

CMake is using libarchive for handling various archive files (including
tar) libarchive seems to have
some feature for progress display (
https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
but CMake code is not using it in any way.


> and yes I'm using cmake -E tar .-.
>
> Any ideas?
>

Beside non-portable way no.


>
> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
> wrote:
>
>> I guess he is using
>>
>> cmake -E tar
>>
>> may be using 'v' verbose option from tar  should be enough.
>>
>> i.e.
>> cmake -E tar xvz your-archive.tar.gz
>>
>> It should display file names as they come out of the archive.
>> So unless your very big archive only contains relatively big files, the
>> output should evolve quite often.
>>
>> Eric
>>
>>
>> Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
>> écrit :
>>
>>> Are you calling tar via a custom command?  tar itself looks to have a
>>> few options to print progress:
>>>
>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>>>
>>> Although none of the options seem to know the archive's size, so aren't
>>> able to print a completion percentage.
>>>
>>>
>>> On 16/12/2018 21:31, Person Withhats wrote:
>>>
>>> When running tar via CMake (in order to use cross-platform work-ability
>>> and what not) it'd be great to have a progress bar of any sort.
>>>
>>> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
>>> information. I'm not aware of any way to do this through CMake directly,
>>> only alternative is e.g. python script that does the untar for me.
>>>
>>> Any suggestions? (sorry if this is reposted, can't remember if acc was
>>> approved before or after sending one time)
>>>
>>>
>>> --
>>>
>>> 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:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>> --
>> Eric
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Tracking progress of CMake TAR

2018-12-17 Thread Eric Noulard
I guess he is using

cmake -E tar

may be using 'v' verbose option from tar  should be enough.

i.e.
cmake -E tar xvz your-archive.tar.gz

It should display file names as they come out of the archive.
So unless your very big archive only contains relatively big files, the
output should evolve quite often.

Eric


Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
écrit :

> Are you calling tar via a custom command?  tar itself looks to have a few
> options to print progress:
>
> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>
> Although none of the options seem to know the archive's size, so aren't
> able to print a completion percentage.
>
>
> On 16/12/2018 21:31, Person Withhats wrote:
>
> When running tar via CMake (in order to use cross-platform work-ability
> and what not) it'd be great to have a progress bar of any sort.
>
> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
> information. I'm not aware of any way to do this through CMake directly,
> only alternative is e.g. python script that does the untar for me.
>
> Any suggestions? (sorry if this is reposted, can't remember if acc was
> approved before or after sending one time)
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04

2018-12-14 Thread Eric Noulard
Did you try to pick a pre-compiled version of CMake?
https://cmake.org/download/

https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz
CMake is statically linked so installing a binary should work.

Le ven. 14 déc. 2018 à 17:48, Paul Jeffries  a
écrit :

> Dear list,
>
> I ultimately want to install a program called DosageConvertor that
> requires a version of cmake that is 3.2 or later. Therefore, I am trying to
> install a more recent version of cmake since the current version is 2.8.7.
>
> When I run ./bootstrap, I get a message that there were problems running
> make: 2 errors generated. make: *** [cmAddCustomCommandCommand.o] Error 1
> (I have added the complete output below.)
>
> I searched and found no clear solution to this problem. I did see that std
> should be set to gnu++11, but my output has “std=gnu++1y”.
>
> I specified the compiler because when I ran ./bootstrap by itself, I got
> an error message that there was no C++ compiler. Did I choose the wrong
> compiler? Am I missing a library?
>
> Any help would be appreciated.
>
> Paul
>
> paul@paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && sudo make 
> install-CMake 3.13.1, Copyright 
> 2000-2018 Kitware, Inc. and ContributorsC compiler on this system is: gcc 
>   C++ compiler on this system is: clang++  -std=gnu++1y Makefile 
> processor on this system is: makeclang++ has setenvclang++ has 
> unsetenvclang++ does not have environ in stdlib.hclang++ has stl 
> wstringclang++ has 
> -clang++ 
> -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk  
> -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake-
> 3.13.1/Source/LexerParser  -I/home/paul/cmake-3.13.1/Utilities  -c 
> /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o 
> cmAddCustomCommandCommand.o In file included from 
> /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:In file 
> included from /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: 
> /home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: exception 
> specification of explicitly defaulted move constructor does not match the 
> cmListFileBacktrace(cmListFileBacktrace&&) // NOLINT(clang-tidy)  ^ 
> /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: exception 
> specification of explicitly defaulted move assignment operator does not match 
> the calculated one cmListFileBacktrace& operator=(cmListFileBacktrace&&) // 
> NOLINT(clang-tidy)   ^2 errors generated.make: *** 
> [cmAddCustomCommandCommand.o] Error 
> 1-Error when bootstrapping 
> CMake:Problem while running 
> make-Log of errors: 
> /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log-paul@paul-VirtualBox:~/cmake-3.13.1$
>
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] [CMake] dependencies of cross compiliations

2018-12-11 Thread Eric Noulard
Le mar. 11 déc. 2018 à 14:18, Rolf Eike Beer  a écrit :

> Eric Noulard wrote:
>
> > When ones do cross compile for the host + one or several target a
> > lighter
> > "add_superbuild" API could be design. I'll try to think about it more
> > thoroughly and do some proposal. Ideally we shouldn't need to provide
> > many
> > parameters beside the toolchain and a way to specify "the host build".
>
> I guess putting the host-build location in the toolchain file could be
> one way
> to just get it done. In case one has multiple builds that should share
> one host
> build then just set an absolute location, and if you don't it will be
> below your
> normal build directory.
>

Yes that seems a reasonable way to do it.

There are just 2 things that scare me a bit off: we surely want a way to
> break
> that into smaller pieces so we can introduce it over multiple releases,
> maybe even
> as a tech-preview so we can break things if we see that we have not
> taken a bigger
> usecase in account, and I currently don't see the points to slice that
> up.
>

We could add new builtin command along with an enable_preview command that
would bring the currently in preview commands.
If you don't call enable_preview CMake will issue an error telling that the
command you are trying to are in "preview" if it's the case.
When enabling preview you'll get the "in-preview" command plus a warning
telling you that enabling preview brings you command/features that are not
guaranteed to be backward compatible.

Equipped with that we could incubate a feature and switch it from preview
to prime-time when we are confident about it.


> And we really, really want a
> .cmake_no_freaking_in_source_build_under_any_circumstances
> or however we gonna call it, and we need that first. There has been
> wasted enough time
> with in-source builds, missing cleanups and all the weird side effects
> in our industry
> for decades, and sadly CMake hasn't stopped that nonsense entirely.
> There are still
> projects out there that can only build this way because they do some
> assumptions on
> where to pick up files, but for something that will end up mixed
> cross/host build this
> will never under any circumstances going to work.
>

Yeah you are damn right, and guess what, I was convinced by that near a
decade ago from now
https://cmake.org/Bug/view.php?id=6672 !!

The old ticket got reloaded in the "new" tracker as
https://gitlab.kitware.com/cmake/cmake/issues/6672


> I wonder if we can't just add it as extra argument to
> cmake_minimum_required(), in a
> way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you
> require a version
> newer than say 3.14, so anyone that is not explicitely requesting this
> to work will
> automagically end up in a "clean" setup. Of course we need to make sure
> that no file is
> written by CMake until that line is parsed (or any other command is
> encountered). Or
> simply do something similar when using toolchain files, which CMake can
> detect before
> even start parsing the main CMakeLists.txt.
>

There is two problems here.

1) AFAIR (there is some discussion about that in the old ticket) as soon as
CMake is parsing CMakeLists.txt it creates the CMakeCache.txt and you want
to avoid polluting the source before that thus the proposal from Ben & Brad
to add the no-in-source enforcement in an extra file.

2) Changing the default behavior of not accepting in-source is good for me
but it is clearly backward incompatible. Unless I'm wrong there has not
been any such backward-incompatible change in CMake as of now.
I doubt this would be widely accepted. Or may be for CMake 4.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] dependencies of cross compiliations

2018-12-10 Thread Eric Noulard
Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > My assumption are:
>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>> have to setup some superbuild
>> >structure for building host tools ht_exe and another for target1
>> tool t1t_exe and another one for target2 tool t2t_exe.
>> >
>> >  b) what you want is to build:
>> >  ht_exe for the host
>> >  possibly use ht_exe during the build to generate some [source] file
>> >  t1t_exe for the [cross]target1
>> >  t2t_exe for the [cross]target2
>> >
>> >  c)  you seldomly compile the same source for the host AND the target,
>> but it may happen.
>>
>> In case, you are doing unit tests, it’s normal to have the same code
>> running in a test on the host platform and in the final binary on the
>> target.
>>
>> I think, having more than 1 target platform becomes more and more normal
>> as it becomes more usual to have multiple microcontrollers in a project.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


>
>> Previously, I have encoded this in the build type. So instead of just
>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>> much, that I have to run CMake 3 times to get all the binaries for a
>> release build. The problem that I have, are dependencies between this
>> builds. If I write a tool that (for example) generates source files for one
>> of the target platforms, the build for the host platform must run before
>> the build for that target platform. And when I make changes to that tool, I
>> want the build to regenerate the generated source files.
>>
>> Keeping track of this dependencies to solve this kind of ordering issues
>> and to allow minimum rebuilds, is the main purpose of any build system. To
>> solve this with CMake, I think we need a way to define the dependencies
>> between build types (in the example above, from the generator from the host
>> build to the generated source file in one of the target builds) and CMake
>> needs to know the build directory for all build types (not only the
>> current).
>>
>
> Perhaps a superbuild would be the cleanest approach here? The host tools
> would be one subproject and the cross-compile builds would depend on the
> host tools' build. You could then choose to build everything via the top
> level superbuild or just work on one of the subprojects if that's all you
> needed once the initial tools build had been done. You could even set up as
> many different sub-projects for the different architectures as needed.
> Packaging would require a little more work, but it shouldn't be
> prohibitively so.
>

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


> Another alternative is the approach described in this stackoverflow
> article
> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
> which performs the host tools build off to the side in a secondary build
> during configure. This works well when the host tools don't change much (we
> use it extensively at work with very large, complex hierarchical projects).
> It wouldn't help though if you need to build more than one cross-compiled
> architecture.
>
> > The wish-season is coming up, so that's sort of what I would like to
>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>
>> How about ``add_dependencies()`` allowing me to define dependencies
>> between different build types? :-)
>>
>
> A superbuild would already give you the equivalent capability.
>

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] [CMake] dependencies of cross compiliations

2018-12-10 Thread Eric Noulard
Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > My assumption are:
>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>> have to setup some superbuild
>> >structure for building host tools ht_exe and another for target1
>> tool t1t_exe and another one for target2 tool t2t_exe.
>> >
>> >  b) what you want is to build:
>> >  ht_exe for the host
>> >  possibly use ht_exe during the build to generate some [source] file
>> >  t1t_exe for the [cross]target1
>> >  t2t_exe for the [cross]target2
>> >
>> >  c)  you seldomly compile the same source for the host AND the target,
>> but it may happen.
>>
>> In case, you are doing unit tests, it’s normal to have the same code
>> running in a test on the host platform and in the final binary on the
>> target.
>>
>> I think, having more than 1 target platform becomes more and more normal
>> as it becomes more usual to have multiple microcontrollers in a project.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


>
>> Previously, I have encoded this in the build type. So instead of just
>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>> much, that I have to run CMake 3 times to get all the binaries for a
>> release build. The problem that I have, are dependencies between this
>> builds. If I write a tool that (for example) generates source files for one
>> of the target platforms, the build for the host platform must run before
>> the build for that target platform. And when I make changes to that tool, I
>> want the build to regenerate the generated source files.
>>
>> Keeping track of this dependencies to solve this kind of ordering issues
>> and to allow minimum rebuilds, is the main purpose of any build system. To
>> solve this with CMake, I think we need a way to define the dependencies
>> between build types (in the example above, from the generator from the host
>> build to the generated source file in one of the target builds) and CMake
>> needs to know the build directory for all build types (not only the
>> current).
>>
>
> Perhaps a superbuild would be the cleanest approach here? The host tools
> would be one subproject and the cross-compile builds would depend on the
> host tools' build. You could then choose to build everything via the top
> level superbuild or just work on one of the subprojects if that's all you
> needed once the initial tools build had been done. You could even set up as
> many different sub-projects for the different architectures as needed.
> Packaging would require a little more work, but it shouldn't be
> prohibitively so.
>

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


> Another alternative is the approach described in this stackoverflow
> article
> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
> which performs the host tools build off to the side in a secondary build
> during configure. This works well when the host tools don't change much (we
> use it extensively at work with very large, complex hierarchical projects).
> It wouldn't help though if you need to build more than one cross-compiled
> architecture.
>
> > The wish-season is coming up, so that's sort of what I would like to
>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>
>> How about ``add_dependencies()`` allowing me to define dependencies
>> between different build types? :-)
>>
>
> A superbuild would already give you the equivalent capability.
>

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] [CMake] dependencies of cross compiliations

2018-12-10 Thread Eric Noulard
Le mer. 28 nov. 2018 à 21:03, Rolf Eike Beer  a écrit :

> Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard:
>
> > I think that most of the time specifying the toolchain on the command
> line
> > drives you to some superbuild structure.
>
> Which is not bad by itself, but I would like to see that CMake can provide
> things that avoid people reinventing the boilerplate code, and probably
> getting them wrong at least 80% of the time. Like they would do with
> dependencies and other things if they would write their Makefiles by hand
> instead of using CMake, just one level higher.
>

I do totally agree with this.
Superbuild is nice but you have to write a lot of boilerplate CMake code
*each time* you want to do it.
May be a good path would be to have a "builtin" support for superbuild in
CMake which
would make its usage lighter than the usual ExternalProject_Add.

When ones do cross compile for the host + one or several target a lighter
"add_superbuild"
API could be design. I'll try to think about it more thoroughly and do some
proposal.
Ideally we shouldn't need to provide many parameters beside the toolchain
and a way
to specify "the host build".


>
> > > The wish-season is coming up, so that's sort of what I would like to
> > > have. Now it's your turn. No bikeshedding please, only deliveries ;)
> >
> > I wish an integrated multi-target cross building support in CMake with
> > little or no flow-control scripting command in the CMakeLists.txt.
>
> That would mean introducing HOST and TARGET flags to every find_* call,
> I'm
> not sure if that is cleaner than explicit if()'s. But I'm not
> fundamentally
> opposed to it, I'm just not sure it's worth the effort.
>

Sure, I agree too.
May not be worth, let's dig the "light superbuild" approach a little
further first.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] New version forces rebuild all?

2018-12-04 Thread Eric Noulard
Le mar. 4 déc. 2018 à 11:44, Andy  a écrit :

> Problem are still.
> Alone make also give me problems.
>

Do you have stripped down project example?


> Ninja is replacement od cmake or make?
>

ninja (https://ninja-build.org/) is make replacement for which there is a
CMake generator.
https://cmake.org/cmake/help/v3.13/generator/Ninja.html


> How work with ninja?
>

1) install ninja (on debian the package is called ninja-build)
2) cmake -G Ninja
3) ninja

this would rule out generator specific issue.
-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Build and run an external project

2018-12-03 Thread Eric Noulard
Le mar. 4 déc. 2018 à 06:11, James Bigler  a écrit :

> Unfortunately I don't think your suggestion will work.
>
> I need to invoke a custom executable to build my project and not a
> msproject.  I also need to copy the executable into the build directory.
>

Sorry I miss the fact that you moved the executable around and was not a
"regular" compile.
I've read your message too fast, obviously, sorry.

I'm not much a Visual Studio user and it has been a long time since I need
to compile something on windows.

You basically require that an executable not built by VS appears as a
"runnable/debuggable" target in VS?
Are you able to do that from VS "manually" ?

Again I'm no VS/Windows specialist so others may have more valuable remark
on that.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Build and run an external project

2018-12-03 Thread Eric Noulard
Did you check whether if
https://cmake.org/cmake/help/latest/command/include_external_msproject.html

wouldn't be better in your case?


Le mar. 4 déc. 2018 01:43, James Bigler  a écrit :

> I have an external project that I would like to compile using their build
> system, and be able to set the VS_COMMAND to the result of the project so I
> can run it.
>
>   add_custom_target(${cmake_target}
> COMMAND make mytarget ${BUILD_ARGS}
> COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${PATH_TO_EXTERNAL}/mytarget.exe ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$
> WORKING_DIRECTORY ${PATH_TO_EXTERNAL}
> )
>   set_property( TARGET ${cmake_target} PROPERTY VS_DEBUGGER_COMMAND
> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/mytarget.exe" )
>
> The VS_DEBUGGER_COMMAND works for targets such as add_executable, but not
> for add_custom_target.
>
> Is there a way to get what I want?
>
> Note that this is part of a larger CMake project that builds most of the
> other stuff using CMake, but I have a few external projects that I would
> like as part of the main solution.
>
> Thanks,
> James
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] [CMake] dependencies of cross compiliations

2018-11-27 Thread Eric Noulard
Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [CMake] dependencies of cross compiliations

2018-11-27 Thread Eric Noulard
Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [CMake] Can an option enforce a default, even if cache is present?

2018-11-27 Thread Eric Noulard
Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer  a
écrit :

>
> Dear all,
>
> I've just discovered that option() behaves differently than I anticipated.
> After reading the docs and searching with google I'm still confused how to
> achieve my desired behaviour.
>
> What I've just learned is that unspecified options take their cached value
> and do *not* go back to their default value, if a cache exists. I assumed
> that options take their default when not explicitly specified.
>

The behavior of option() gained new behavior in CMake 3.13.
May be it could help in your particular case:
https://cmake.org/cmake/help/v3.13/policy/CMP0077.html#policy:CMP0077

you'll depend on latest CMake though.


>
> Now my problem: I could not find a way to get the behaviour I'd like. Is it
> possible to enforce the default for an option when its not specified by the
> user, even if a cache exists?
>

You mean you did not manage to force the cache value?
You can:
set(VAR "default_value" CACHE FORCE)

or the problem is you cannot know whether if a value has been user-provided?


> I tried to unset() the option from the cache but that does not do what I'd
> like.
>
> All the best,
>
> Mario Emmenlauer
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

2018-11-27 Thread Eric Noulard
Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer  a
écrit :

>
> Dear Eric,
>
> just to let you know, your suggestion of using a post-install-script
> for all system-wide links and files was indeed the solution to a working
> RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
> and install works fine.
>

Thank you very much for the *positive* feedback, we don't always get those
:-)

This is nice to me and probably useful to others knowing it finally works.

Cheers,
Eric

Cheers and Thanks,
>
>Mario
>
>
>
> On 23.11.18 15:37, Mario Emmenlauer wrote:
> >
> > Dear Eric,
> >
> > thanks a lot for this help! I think I have the pointers to move forward!
> > One more detail below:
> >
> > On 23.11.18 11:36, Eric Noulard wrote:
> >> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer  <mailto:ma...@emmenlauer.de>> a écrit :
> >> Dear Eric, thanks for the help! Below more:
> >>
> >> On 22.11.18 18:20, Eric Noulard wrote:
> >> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <
> ma...@emmenlauer.de <mailto:ma...@emmenlauer.de>  ma...@emmenlauer.de
> >> <mailto:ma...@emmenlauer.de>>> a écri
> >> > I'm trying to build an RPM with CPack, and everything seems
> to work,
> >> > but the resulting package can not be installed. I get
> Transaction check
> >> > error:
> >> >   file / from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >> >   file /opt from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/bin from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/share from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >
> >> > I've read in the CPackRPM source code about how to add
> excludes and
> >> > CPackRPM says that my "Final list of path to OMIT in RPM"
> would be
> >> >
>  
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> >> >
> >> >
> >> > You can read the doc too:
> >> >
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
> >>
> >> Haha, done that! I've read everything I could find, including the
> >> docs and the excellent but hard-to-find community wiki at
> >> https://gitlab.kitware.com/cmake/community/wikis/home
> >>
> >>
> >> OK then you are up-to-doc then.
> >>
> >> > Could someone shed some light? I believe that the problem may
> be
> >> > my install command: I call install only once for the full tree
> >> > of files that I'd like to package:
> >> >   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
> >> >
> >> > Yep this is looking for trouble.
> >> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> >> >
> >> > Can't you use relative path install DESTINATION ? For all
> files/target you build?
> >>
> >> I'm not sure if I can use a relative path. I want to build a system
> package
> >> that installs to /opt// with symlinks in /usr/bin/ and
> desktop
> >> files in /usr/share/applications/. Since files go into different
> paths below
> >> system root (/opt, /usr, maybe /var) I assume I need to install
> into root?
> >> Maybe I misunderstand?
> >>
> >>
> >> Not really. Usually you install in relative bin/ share/ man/ whatever
> other subdir you need.
> >> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see
> https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
> )
> >> to set up your "main" install prefix for your package. Every CPack
> generator has a default **packaging install prefix** (not to be confused
> with
> >> CMAKE_INSTALL_PREFIX).
> >> In your case:
> >> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
> >> which should even be (AFAIR) the default value for RPM and DEB.
> >>
> >> Concerning the

Re: [CMake] CPU specific compiler flags

2018-11-26 Thread Eric Noulard
Le lun. 26 nov. 2018 à 09:36, Ciccio Pasticcio 
a écrit :

> Hi all,
>
> I'm refactoring some libraries cmake files to be compliant to the use of
> targets instead of tons of variables. Since these libraries are
> cross-compiled I'm facing some problem finding how to properly set some
> specific flags like: -march -marm -mfloat-abi etc. For now I set the
> CMAKE_CXX_FLAGS:
>
> set(CMAKE_CXX_FLAGS -march=armv7-a -marm -mthumb-interwork
> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -Wno-psabi)
>
> Is this the only way to do this?
>

I'm not sure to understand, you can perfectly setup flags on a target
specific way using 'target_compile_option'
https://cmake.org/cmake/help/latest/command/target_compile_options.html

If all your libraries are in a common directory you can use,
COMPILE_OPTIONS property on the directory
https://cmake.org/cmake/help/latest/prop_tgt/COMPILE_OPTIONS.html#prop_tgt:COMPILE_OPTIONS
to avoid repetition for each lib.

All that said, if you are cross-compiling those I bet you are using a
toolchain file (
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling
)
so if those "target-specific" compile options are global to your target
then you may set
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html#variable:CMAKE_%3CLANG%3E_FLAGS
in the toolchain.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

2018-11-23 Thread Eric Noulard
Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer  a
écrit :

>
> Dear Eric, thanks for the help! Below more:
>
> On 22.11.18 18:20, Eric Noulard wrote:
> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer  <mailto:ma...@emmenlauer.de>> a écri
> > I'm trying to build an RPM with CPack, and everything seems to work,
> > but the resulting package can not be installed. I get Transaction
> check
> > error:
> >   file / from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /opt from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /usr/bin from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /usr/share from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >   file /usr from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >
> > I've read in the CPackRPM source code about how to add excludes and
> > CPackRPM says that my "Final list of path to OMIT in RPM" would be
> >
>  
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> >
> >
> > You can read the doc too:
> >
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>
> Haha, done that! I've read everything I could find, including the
> docs and the excellent but hard-to-find community wiki at
> https://gitlab.kitware.com/cmake/community/wikis/home


OK then you are up-to-doc then.

> Could someone shed some light? I believe that the problem may be
> > my install command: I call install only once for the full tree
> > of files that I'd like to package:
> >   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
> >
> > Yep this is looking for trouble.
> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> >
> > Can't you use relative path install DESTINATION ? For all files/target
> you build?
>
> I'm not sure if I can use a relative path. I want to build a system package
> that installs to /opt// with symlinks in /usr/bin/ and desktop
> files in /usr/share/applications/. Since files go into different paths
> below
> system root (/opt, /usr, maybe /var) I assume I need to install into root?
> Maybe I misunderstand?
>

Not really. Usually you install in relative bin/ share/ man/ whatever other
subdir you need.
Then you define CPACK_PACKAGING_INSTALL_PREFIX (see
https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
)
to set up your "main" install prefix for your package. Every CPack
generator has a default **packaging install prefix** (not to be confused
with CMAKE_INSTALL_PREFIX).
In your case:
set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
which should even be (AFAIR) the default value for RPM and DEB.

Concerning the symlink in /usr/bin (or other places /usr/share etc...) this
usually done using post-install script
https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE

the script itself may call standard symlink creation like
https://linux.die.net/man/8/update-alternatives

Sometimes you *really* need absolute prefix like when you install in
/etc/init...
then for those (generally system) specific file you install them with
absolute destination.
CPackRPM is able to handle those as "config" file automatically.

> I have a wild guess that this install somehow includes the
> > directories, and probably it would be better to just call install
> > on the individual files?
> >
> > CPack RPM tries its best to avoid shipping directories he does not need
> to ship, but
> > RPM requires that any new (non shared) directory should be specified in
> the spec file,
> > so CPackRPM tries to "discover that" automatically and make the package
> relocatable.
> >
> > Installing a whole directory to an absolute DESTINATION (even "/" in you
> case) is probably
> > giving tough time to CPackRPM.
>
> There is something I don't understand: I can see that CPackRPM removes
> several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
> about several of the removed items nonetheless. For example /usr/bin.
> Does that mean the filtering failed, or does the filter work but (somehow)
> the directory still ends up being packaged?
>

Evil usually hides in details.

Difficult to say without having the actual code and package to look into it.
Is your project public? If so could you provide us

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

2018-11-22 Thread Eric Noulard
Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer  a écri

>
> I'm trying to build an RPM with CPack, and everything seems to work,
> but the resulting package can not be installed. I get Transaction check
> error:
>   file / from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>   file /opt from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>   file /usr/bin from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
>   file /usr/share from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
>   file /usr from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>
> I've read in the CPackRPM source code about how to add excludes and
> CPackRPM says that my "Final list of path to OMIT in RPM" would be
>
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>

You can read the doc too:
https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST


I can see that the conflicting directories are removed from
> CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(
>
> Could someone shed some light? I believe that the problem may be
> my install command: I call install only once for the full tree
> of files that I'd like to package:
>   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
>

Yep this is looking for trouble.
How did you build the "${INSTALL_TMP_ROOT}" in the first place?

Can't you use relative path install DESTINATION ? For all files/target you
build?


> I have a wild guess that this install somehow includes the
> directories, and probably it would be better to just call install
> on the individual files?


CPack RPM tries its best to avoid shipping directories he does not need to
ship, but
RPM requires that any new (non shared) directory should be specified in the
spec file,
so CPackRPM tries to "discover that" automatically and make the package
relocatable.

Installing a whole directory to an absolute DESTINATION (even "/" in you
case) is probably
giving tough time to CPackRPM.


> I would prefer not to call install on the
> individual files because that overrides file permissions for every
> file, and I carefully prepared my package upfront to have the
> exact permissions for installation.
>

How did you "carefully prepared my package upfront" ?
And what do you mean by
"because that overrides file permissions for every file"

one more question, could you tell us which version of CPack/CMake you are
using?


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] How to find GTK3 in CMake

2018-11-21 Thread Eric Noulard
Le mer. 21 nov. 2018 à 09:46, David Demelier  a
écrit :

> Le 20/11/2018 à 17:03, Harry Mallon a écrit :
> > Hi,
> >
> > FindGTK and FindGTK2 exist in the CMake tree. How come there isn't one
> for GTK3? Should the GTK2 one work, or is there another way?
>
> GNOME people don't like CMake (they use meson). The philosophy behind
> CMake is to let upstream projects provides their own CMake configuration
> packages rather than providing Find modules for every single library
> existing in the world.
>

Right and the fact is even traced here:
https://gitlab.kitware.com/cmake/cmake/issues/15888



>
> CMake should already not provide any of these, but this general
> recommendation came after.
>
> It's the same thing for pkg-config, pkg-config by itself does not
> provide any .pc file.
>
> Also, Gtk is much more tied to Linux than being portable. I think that's
> why portable software don't use Gtk that much and thus, not CMake either.
>

Some project nevertheless uses GTK3 and CMake so that you may borrow
hopefully working
FindGTK3.cmake module from them:
E.g.
Darktable:
https://redmine.darktable.org/projects/darktable/repository/changes/cmake/modules/FindGTK3.cmake
WebKit:
https://github.com/WebKit/webkit/blob/master/Source/cmake/FindGTK3.cmake

and probably many others.
-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

2018-11-21 Thread Eric Noulard
Le mar. 20 nov. 2018 à 22:40, Oleh Kravchenko  a écrit :

> 20.11.18 23:29, Brad King wrote:
> > SOURCE_DATE_EPOCH was created for use by packagers where tools
> > already wrap the build.  By making it an environment variable
> > packagers could jump through any number of build system layers
> > with no patching.
>
> That's makes me confused, because CMake has CPack.
> And with CPack process looks like:
> - `cmake && make package`
> So there are no any packagers tools, all work done with CMake.
>

The package tool here is CPack.
You consider CMake and CPack as monolithic software they were not designed
this way (and I personally find it nice to be so).

CMake and CPack (or CTest) may work together but they may well be used
independently.
Moreover they do not run at the same time, have a look at the figure here:
https://github.com/dev-cafe/cmake-cookbook/blob/master/figures/cmake-times/cmake-times.jpg

And you may see that setting environment var at configure time is
relatively far away from packaging time.

All that saif you are right CPack may honor SOURCE_DATE_EPOCH, and CMake
"may" forward the usage
of SOURCE_DATE_EPOCH from configuration time down to CPack time.

At least one CPack generator (the DEB one) recently honor SOURCE_DATE_EPOCH
https://gitlab.kitware.com/cmake/cmake/commit/548ac51d8ea319c65abefa0a771636893c45014c


If you use a
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for your project
you may easily set the SOURCE_DATE_EPOCH env var at CPack time, i.e. when
CPack runs.



> > Build systems configure compilers with command-line flags, not
> > environment variables.  If you want to do this from within the
> > build system then GCC could be taught a new option for that.
>

Apparently gcc team decided to use env var for that:
https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
see associated discussion (I did not read it all):
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html

llvm/clang discussion on this does not seem to be closed:
https://reviews.llvm.org/D23934


> >
> > You could try hacking it with `CMAKE__COMPILER_LAUNCHER`:
> >
> >
> https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html
> >
> > e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or
> >
> > ```cmake
> > set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
> > ```
>
> Thank you, I will try that.
>

AFAIU this should already work with gcc.

I discovered https://reproducible-builds.org/, while reading your question.
The goal is nice, and I think CMake/CPack should support that for
compiler/[package] build tools that support it.

I won't have time to work on patches for that but I'll certainly take time
to read/test one if someone is working on it.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] cmake 3.12 - python libs / 32 / 64 bits

2018-11-15 Thread Eric Noulard
Le jeu. 15 nov. 2018 à 09:47, Stéphane Ancelot  a
écrit :

> I agree. That was a debug snippet...but is wrong ... I setted up again the
> toolchain, but does not help.
>

If you are using a proper toolchain for 32bit compilation.
It looks like a bug in the find_package for Python in the cross-compiling
case.
Do you have a stripped down example which exhibit the issue?
Which version of CMake are you using?


>  So, I know where are include_dirs and libs  for 32 bits cross compiling,
> I have to hardcode it like this ?
>
>  add_library(python SHARED IMPORTED)
>  set_target_properties( python PROPERTIES IMPORTED_LOCATION /usr/lib32/
> libpython2.6.so )
>  target_include_directories(python SYSTEM ...
>

I think you can do that but it replaces the use of find_package(Python2
COMPONENTS Development)
may be fixing this would be a better long-term solution ?



>
>
> Le 14/11/2018 à 17:53, Marc CHEVRIER a écrit :
>
> The way you proceed is wrong.
> The system configuration is determined during the 'project' function call.
> Setting information after this call is useless. So, in your example, on a
> 64bit system, the compilation configuration will be 64bit (variable
> CMAKE_SIZEOF_VOID_P has value 8).
> This explain why 'FIND_LIBRARY_USE_LIB32_PATHS' has no effect. This
> property is taken in consideration only on 32bit systems.
>
> Moreover, I am not sure that modifying variable 'CMAKE_SYSTEM_PROCESSOR'
> is a valid action.
>
> To configure a 32bit compilation environment, two possibilities:
> * using environment variables: env CFLAGS=-m32 CXXFLAGS=-m32 cmake ...
> * using a toolchain file: see
> https://cmake.org/cmake/help/v3.13/manual/cmake-toolchains.7.html
>
>
> Le mer. 14 nov. 2018 à 14:06, Stéphane Ancelot 
> a écrit :
>
>> Hi,
>>
>> My system is 64 bits but I can cross compile python c modules for 32 bits
>> .
>>
>> Unfortunately I don't manage to retrieve python 32 libs , always the 64
>> bits version is found.
>>
>>
>> here is what I tried :
>>
>> cmake_minimum_required(VERSION 3.10)
>> project(py_autom)
>>
>>
>> set(CMAKE_SYSTEM_PROCESSOR "i686")
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
>> set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
>>
>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
>>
>> include_directories(python2.6)
>> find_package(Python2 COMPONENTS Development)
>>
>>
>>
>> message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR}
>> ${Python2_FOUND}")
>>
>> Regards
>>
>> Steph
>> --
>>
>> 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:
>> https://cmake.org/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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Tips on reducing configure time

2018-11-14 Thread Eric Noulard
Le mer. 14 nov. 2018 à 13:25, Poughon Victor  a
écrit :

> Yes you are correct on all your observations. We already use ninja and
> ccache wherever we can. In fact we have an issue about the whole end-to-end
> build performance where we track all effort on this throughout the project
> (if you're interested:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649)
>

End-to-end build performance is a subject of interest to me, I'll have a
look.


> There are indeed quick and easy wins to be had with those tools (and we
> are working on it). But my original question is not about that. It's about
> speeding up the configure step with makefile generator. I still don't think
> it's normal that it does hundreds of thousands of I/O on files that are a
> few bytes or even empty. However it's possible that it's because we do
> something incorrect in our CMakeLists.txt and not CMake's fault.
>

I don't really know makefile-generator internals so I cannot tell.
For sur the current OTB build dir constructed with Makefile generator is
spitting out around 180 Makefile.
May be you can profile the cmake execution by building a debug version of
CMake and collect more precise insight on where the bottlenecks may reside.

You may track try_compile which could obviously be slow and may be
configure_file as well.
Otherwise I don't know, I guess you'll have to profile the cmake run.

It's true that a few minutes of configure is not much when doing a full
> build, but consider incremental builds where all you do is change one cxx
> file (and cmake is triggered because you changed git branch or something).
> Then the generate step is a significant part of the time you wait.
>

Yes that right.
Note however that changing git branch should nor per-se trigger a cmake run.
Only changing a CMakeLists.txt or configured file or explicitely specified
by
CMAKE_CONFIGURE_DEPENDS.

Otherwise changing branch with git that only modifies source shouldn't
trigger cmake rebuild.
I do that all the time in a classical git branch dev model.



-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Tips on reducing configure time

2018-11-14 Thread Eric Noulard
Le mer. 14 nov. 2018 à 12:06, Poughon Victor  a
écrit :

> Thanks for the replies
>
>
>
> You can see configure times on our dashboard (switch to advanced view):
> https://dash.orfeo-toolbox.org/index.php?project=OTB
>
> It ranges from 1-3min. There's even one windows machine that's at 4m30s.
>

Somes windows system are known to be slow on many files accesses.
However on this particular machine (
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342008 I guess) you
already seem
to be using NInja + MSVC. so many small files access to ?makefiles? should
not be the culprit.

That said whatever the system your build and test time seems to dominate
the overall time (in the CI).

I have had great speed-up experience using CMake+ninja+ccache  for our
build in CI. We did go from 1 hour down to less than 10min.
We only have various linux build (no Windows) it is really a big time
savior combo.

We even share the compil' cache between the CI and the developers. So
everybody is feeding compile cache and takes benefits from others including
CI.

You seem to be using that as well here:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=341993
and you get less than 5min build time which corroborate my suggestion.

The same machine build with clang:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342033 is lasting
30min+
and is not using ccache.


> Thanks for the tip about Ninja generator, it's indeed much faster. But
> switching the entire dev team + CI servers from make to ninja is not really
> an option for us right now because of a bug in ninja that affects our
> SuperBuild configuration (see here if you're interested in the details:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1625)
>

I see.
Not using ninja in the Superbuild case does not mean you cannot use it in
other cases, right?
May be the one-size fits all is a little too much to ask at this point? My
opinion though.
Did you report the issue upstream (ninja or cmake)?

I was impressed in the past by the amount of tests orfeo is doing, I'm
still are !!
Are you running those tests in parallel (with ctest --parallel) ? It can be
a time savior as well is the running machine has a fair amount of cores and
memory.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Tips on reducing configure time

2018-11-14 Thread Eric Noulard
Hi Victor,

Le mer. 14 nov. 2018 à 10:20, Poughon Victor  a
écrit :

> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure step needs to be re-run, or for CI in general.
>

Could you give us a clue on "takes quite a lot of time"?
Are we speaking of tens of seconds, minutes etc... ?


>
> We have looked into it a bit and it seems like one issue is that the
> configure/generate steps do a lot of small files I/O. Specifically, using:
>
> inotofy-wait -mr 
>
> shows that "cmake ." causes about 150K file access/modify, etc. There are
> some especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp'
> that appear thousands of times in most of the log file.
>
> I have an SSD which somewhat helps, but for colleagues still on mechanical
> drives this is especially painful. Is there a way to disable writing all
> those files to the disk?
>
> Any other tips on optimizing the performance of 'cmake .'?
>

Did you try to test drive a switch to ninja generator ?
Ninja generator generates only two files (build.ninja and rules.ninja) you
won't have the "mny small files issue".
You can have long configuration times as well but not coming from file
access.




>
> Thanks,
>
> Victor Poughon
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] Preferred case for macro names?

2018-11-13 Thread Eric Noulard
Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER  a
écrit :

> I agree as well that trying to distinguish macros from functions is not a
> good idea because functions can act in the same way as macros (i.e.
> changing calling environment) but with a better control over environment
> changes (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>
> so also +1 for lower case for every function, macro or builtin. And good
> point to standardize  macro or function OPTION to UPPERCASE.
>
> Now, for variables, the problem is a bit different because they are case
> sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two
> different variables.
>

Yes damn right.


> My personal tendency is to use lower case for local variables and upper
> case for global variables. May be we can normalize variables to upper case
> regarding global variables used by CMake itself (which is globally the
> current rule).
>

Having a convention for local is nice and I tend to prefix with _ (single
or double) variables that should be local.
lowercasing locals is fine too, however I think that enforcing casing on
"user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and
CPACK_
I guess they already are all UPPERCASE so we may stick with this as a
convention?

A small quote to the cmake-format (
https://github.com/cheshirekow/cmake_format) tool which is trying to
beautify CMakeLists.txt, I'm not using it on complex projects
because it still has some issues but I find it otherwise useful.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Preferred case for macro names?

2018-11-13 Thread Eric Noulard
Le mar. 13 nov. 2018 à 00:21, Craig Scott  a
écrit :

>
>
> On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke 
> wrote:
>
>> My understanding was that prevalent usage in modern CMake
>> is all lowercase for function names, all uppercase for
>> macro names. In this sense, I submitted a number of merge
>> requests where function and macro names are normalized, and
>> in
>>https://gitlab.kitware.com/cmake/cmake/merge_requests/2607
>> I suggest an explicit recommendation in the macro and
>> function doc pages.
>>
>> Now I am learning from Craig Scott that the more recent
>> convention is actually all lowercase for macros as well
>> as for functions.
>>
>
> To be clear, my understanding is that in the past (many years ago),
> uppercase tended to be common, but I don't see that used much these days
> for functions, macros or built-in commands. The general sentiment seems to
> be that uppercase tends to be a bit "shouty" now. I'm suggesting that if
> we're going to bring some consistency to the docs, I propose that we just
> go with lowercase everywhere (functions, macros, built-in commands and
> examples).
>
> 
> Regarding the finer points of macros versus functions versus built-in
> commands and establishing a convention, it's actually a bit difficult to
> draw a hard line in behaviour across all three. Consider commands like
> find_package() and project(). These are built-in commands, but they behave
> like a macros in that they add variables to the calling scope (yes,
> functions can do that too, but the primary reason to use macros is to
> inject variables into the calling scope). Most built-in commands act more
> like functions and do not modify the calling scope. Trying to decide
> whether built-in commands act like macros and which do not and making them
> upper or lowercase based on that is unlikely to be a distinction that most
> users would make, so a mix of upper and lowercase for built-in commands
> would be unexpected. A consequence of this is that having macros and
> functions with differing case conventions would seem to create a potential
> inconsistency with whatever convention is used for built-in commands. The
> only way to really have consistency here would seem to be just use the one
> case convention, for which lowercase seems to be the logical and
> increasingly prevalent choice.
> 
>

I would add that sometimes useful macro/function may become builtin
See example for include_guard in
https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt

So differentiating macro/function/builtin by their case does not seems a
good option to me.
My personal opinion though.

+1 for lower case for every function, macro or builtin.
macro or function OPTION are UPPERCASE
properties are UPPERCASE as well
and I personnally tend to define CMake VARIABLES as uppercase too.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] CPack disable build all

2018-11-09 Thread Eric Noulard
Le ven. 9 nov. 2018 à 17:22, DKLind  a écrit :

> I have a very large project where each sub-project creates a debian
> package.
>
> When "make/ninja package" is specified, it performs a "make/ninja all"
> before packaging. I would prefer to perform a "make/ninja all" myself
> before
> I doing a "make/ninja package".
>
> I want to create a package for just one target. I can use "cpack -D
> CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to
> create the package. I can only surmise that CPack is building everything in
> the background, as there is no output. If I have everything build BEFORE i
> run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds.
>

I'm almost sure that when invoked on itself like:

cpack -G TGZ

cpack does not build at all.
cpack does install but AFAIK it does not trigger the build.

you can try:

ninja clean
cpack -V -G TGZ

and I'm pretty sure CPack will fail because it won't find the expected bits
to be installed precisely because they are not built.

Note that using "-V" verbose option of CPack you'll more traces of what
CPack does.


> Is it possible to disable CPack from building everything?
>

If you observe that could you send us a stripped down project that exhibit
this behavior?

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] option to prevent in-source builds

2018-11-09 Thread Eric Noulard
Just a small remark to say this request of "builtin" way to forbid
in-source is quite old:
https://gitlab.kitware.com/cmake/cmake/issues/6672
which find its origin in:
https://cmake.org/Bug/view.php?id=6672

I don't know if the note from that initial discussion are valid nowadays
but the fact that:
"Code in CMakeLists.txt is not even executed until after the cache is
initialized so there would have to be some other way to indicate in the
source tree that it should not be built in-source."
and the fact that
"The cache is initialized before the procedural steps start to run. With
cmake-gui or the cmake command-line "-D" option it is even possible to
store entries in the cache before CMake even parses CMakeLists.txt"
almost implies that this should be done outside CMakeLists.txt

That said, I think that
I would rather have some obviously visible and fixed place like
CMakeInit.json that should be located in the very same directory as the
concerned CMakeLists.txt rather than some list of possible places (cmake/,
cmake/init, .cmake, etc...). The exact path to CMakeInit.json could be
overwritten by some new command line option, like --init-file if for some
reason we want
a configurable place (may be used in various CI scripts occasion).
This file could hold more options than "just forbid in-source" it could
indicate a default generator (which may be different from the usual default
generator on the concerned platform),
some a toolchain. It's usage would be different than the initial cache
precisely because it could work before cache is created.


Le ven. 9 nov. 2018 à 17:03, Ben Boeckel  a écrit :

> On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote:
> > A lot of projects that use CMake already have a `./cmake` directory, I
> > would think `./cmake/init.json` would fit nicer as opposed to the hidden
> > directory. I'm not a fan of hidden directories in software projects
> anyway.
>
> There are also `./CMake` directories. HDF5 uses `./config/cmake`. I
> think just claiming a "hidden" directory with exact casing is better.
>
> --Ben
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

2018-10-23 Thread Eric Noulard
Le mar. 23 oct. 2018 à 12:06, Craig Scott  a
écrit :

>
>
> On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard 
> wrote:
>
>> Le lun. 22 oct. 2018 à 23:05, Craig Scott  a
>> écrit :
>>
>>>
>>>> Yes I agree that having build rpath is useful.
>>>> I am not aware of any mechanism that enable calling some tool during
>>>> CPack's install step.
>>>> Moreover I don't use MacOS at all so I don't have any experience with
>>>> PackageMaker.
>>>>
>>>> May be some Mac user may shed some more light on this.
>>>>
>>>
>>> You should be able to do this using install(SCRIPT) or install(CODE),
>>> invoking the code signing through execute_process() as part of that
>>> script/code.
>>>
>>
>> I wasn't sure of that.
>>
>> So just to be clear  do we know for sure that install(SCRIPT)
>> install(CODE) will run after the CMake builtin-generated install scripts?
>> The builtin generated install script for target includes stripping, so
>> for signing to work as expect we should be sure of the execution order?
>> Or may be you suggest not to install(TARGET) for the concerned target and
>> write install(SCRIPT) replacement for those?
>>
>
> My understanding is that install() commands are generally processed in the
> order in which they appear in the directory scope. It is unspecified how
> the order between directory scopes behaves, although this merge request
> <https://gitlab.kitware.com/cmake/cmake/merge_requests/2434> (now merged
> to master) makes things much more predictable.
>
> I missed the earlier detail about when stripping occurred in relation to
> installing. From what I can see, I think the stripping happens right after
> the executable is copied/installed. Have a look at the generated
> cmake_install.cmake file for one of your builds and search for
> CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own
> install(CODE) or install(SCRIPT) calls after you've done the
> install(TARGETS) calls, I would expect them to come after the stripping,
> but I haven't tested this.
>

I'll have a look, not that I need it but I'd like to know.
Thank you Craig.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] how to debug CPack creation

2018-10-23 Thread Eric Noulard
Le mar. 23 oct. 2018 à 08:07, Илья Шипицин  a écrit :

> Eric, thank you for your review.
> I still wonder why is it so complicated (my expectation was "ok, since I
> use both cmake and cpack, they should work together")
>

The main reason is that CPack was first design as a standalone tool that
can be used without CMake.
I guess that some project may still be using that way.
CMake has a "simple" way to generate CPackConfig.cmake file that drives the
CPack run but you can generate those files
by other mean and still be using CPack, without CMake.



> can you please review
> https://github.com/SoftEtherVPN/SoftEtherVPN/commit/139fffe6e0c218f580cd8a397d94856be37fa947
> (it is based on your suggestions)
>

I made comment on this commit, basically don't generate *any* file in
source tree it's a [relatively] bad habit.
If a file is an artefact of the build then it belongs to build tree.

As a matter of fact you CI build tree seems to /tmp (from your
configure script) but if ever this is changing it'll break the build
use CMAKE_BINARY_DIR.

I think it should work now but your CI will show you if it's ok.

Now concerning your CMAKE_INSTALL_PREFIX if your CI is producing ready to
use .deb / .rpm etc... package then
you'd better use "/opt" as a prefix as suggested by Craig.




> сб, 20 окт. 2018 г. в 17:59, Eric Noulard :
>
>>
>>
>> Le sam. 20 oct. 2018 à 10:54, Илья Шипицин  a
>> écrit :
>>
>>>
>>>
>>> сб, 20 окт. 2018 г. в 13:30, Eric Noulard :
>>>
>>>>
>>>>
>>>> Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a
>>>> écrit :
>>>>
>>>>> hi,
>>>>>
>>>>> we use cmake/cpack for mangling systemd scripts
>>>>>
>>>>>
>>>>> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>>>>>
>>>>> what happens:
>>>>>
>>>>> (*) deb installs files to /usr/libexec
>>>>> (*) cmake sets location as /usr/local/libexec
>>>>>
>>>>
>>>> It looks like your get default "/usr/local" prefix from somewhere.
>>>>
>>>
>>> exactly.
>>>
>>
>> So I I understand it well (correct me if I'm wrong) when you do:
>>
>> 1) make install
>> You get all installed files prefixed by /usr/local
>> which is the expected behaviour unless you configure
>> CMAKE_INSTALL_PREFIX
>> or you use
>> DESTDIR=/your/prefix make install
>>
>> 2) deb created by CPack get "/usr" prefix instead
>>which is the expected behaviour unless you specify an alternate value
>> using
>>CPACK_PACKAGING_INSTALL_PREFIX
>>
>> go to your build tree and try:
>> cpack -G DEB -D  CPACK_PACKAGING_INSTALL_PREFIX=/opt
>>
>> and you'll see that the .deb will have /opt prefix.
>>
>> The question is what do expect as a prefix?
>> /usr/local
>> /usr
>> something else ??
>>
>> The rules are the following when using install rule.
>> 1) if your DESTINATION is a relative path then it will be prefix with
>>CMAKE_INSTALL_PREFIX when doing make install
>>CPACK_PACKAGING_INSTALL_PREFIX when building package with CPack
>>
>> 2) if your DESTINATION is "absolute" like /etc/whatever/confdir
>> It'll get install there when doing make install (whatever the value
>> of  CMAKE_INSTALL_PREFIX)
>>
>> With CPack, it depends on the generator.
>>Some generators (like DEB a,nd RPM) try to catch "absolute" install
>> file and handle them
>>as config file. RPM generator is more verbose about it see below.
>>
>> Is the RPM containing what you expect?
>>>>
>>>
>>> I did not check it yet.
>>>
>>
>> I tried using:
>> $  cpack -G RPM
>>
>> and you get expected warning about the mix of absolute and relative
>> install path:
>> CPack: Create package using RPM
>> CPack: Install projects
>> CPack: - Install project: SoftEtherVPN
>> CPack: -   Install component: vpnserver
>> CPack: -   Install component: vpnclient
>> CPack: -   Install component: vpnbridge
>> CPack: -   Install component: vpncmd
>> CPack: Create package
>> CMake Warning (dev) at
>> /home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:135
>> (message):
>>   CPackRPM:Warning: Path /lib/systemd/system/softether-vpnbridge.service
>> is
>>   not on one of the relocatable paths! Package will be partially

Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

2018-10-22 Thread Eric Noulard
Le lun. 22 oct. 2018 à 23:05, Craig Scott  a
écrit :

>
>> Yes I agree that having build rpath is useful.
>> I am not aware of any mechanism that enable calling some tool during
>> CPack's install step.
>> Moreover I don't use MacOS at all so I don't have any experience with
>> PackageMaker.
>>
>> May be some Mac user may shed some more light on this.
>>
>
> You should be able to do this using install(SCRIPT) or install(CODE),
> invoking the code signing through execute_process() as part of that
> script/code.
>

I wasn't sure of that.

So just to be clear  do we know for sure that install(SCRIPT) install(CODE)
will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for
signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and
write install(SCRIPT) replacement for those?


Taking a step back though, I don't know what your package contains, but if
> you're creating an app bundle, then you don't need CPack at all. An app
> bundle is already self contained and you should be able to get it to build
> with install RPATH, at which point it should find everything it needs. An
> advantage of building with install RPATH is that you can also make use of
> the XCODE_ATTRIBUTE target property support to set up the code signing and
> have Xcode/xcodebuild drive the whole code signing process for you. It's
> likely to be easier that way and is more compatible with tools like
> Fastlane , if you end up heading in that
> direction. But if you have embedded frameworks, then yeah, you probably end
> up having to do things manually yourself (CMake doesn't yet handle those
> well and has no direct support for it).
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
> 
>

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

2018-10-22 Thread Eric Noulard
Le lun. 22 oct. 2018 à 11:56, Anatoly Belyaev  a écrit :

> We use "PackageMaker" generator on MacOS.  But i don't think it is CPack
> specific tool does call strip command.  The code for RPATH rewrite and
> strip cmd is located in cmake_install.cmake. As i understand CPack calls
> make install to tmp dir and then creates package.
>

Sorry I've just realized it was in the title of your message.
I wasn't aware that stripping was done during install.


> Having different RPATH for build tree is useful. May be there is a way to
> call sign tool in the install stage? But reading the doc to CMake install
> command, doesn't help me find solution for this.
>

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during
CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with
PackageMaker.

May be some Mac user may shed some more light on this.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] how to debug CPack creation

2018-10-20 Thread Eric Noulard
>
>
> And the content is:
> $ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
> /lib
> /lib/systemd
> /lib/systemd/system
> /lib/systemd/system/softether-vpnserver.service
> /usr/libexec
> /usr/libexec/softether
> /usr/libexec/softether/vpnserver
> /usr/libexec/softether/vpnserver/hamcore.se2
> /usr/libexec/softether/vpnserver/vpnserver
> /usr/local
> /usr/local/bin
> /usr/local/bin/vpnserver
>
> the content of the .deb is similar:
> $ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/system/
> -rw-r--r-- root/root   700 2018-10-20 14:45
> ./lib/systemd/system/softether-vpnserver.service
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/softether/
> drwxr-xr-x root/root 0 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/
> -rw-r--r-- root/root   1770716 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/hamcore.se2
> -rwxr-xr-x root/root   2088960 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/vpnserver
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/bin/
> -rwxr-xr-x root/root72 2018-10-20 14:45 ./usr/local/bin/vpnserver
>
> The main question is, what filesystem layout do you expect for those files?
>
>
Now I think I get it.
IN vpnserver CMakeLists.txt you do:

install_systemd_service("vpnserver"
"${CMAKE_SOURCE_DIR}/systemd/softether-vpnserver.service"
"${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver")

So at this point (during CMake config step)
"${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver"
is /usr/local/softether/vpnserver/vpnserver

In your install_systemd_service CMake macro wrapper you do:

macro(install_systemd_service component file_path binary_path)
get_filename_component(file_name ${file_path} NAME)
get_filename_component(binary_directory ${binary_path} DIRECTORY)

file(READ ${file_path} FILE_CONTENT)
string(REPLACE "[DIRECTORY]" ${binary_directory} FILE_CONTENT
${FILE_CONTENT})
string(REPLACE "[BINARY]" ${binary_path} FILE_CONTENT ${FILE_CONTENT})
file(WRITE ${CMAKE_SOURCE_DIR}/tmp/systemd/${file_name} ${FILE_CONTENT})
...

So you generate a systemd service file which contains /usr/local prefix
because this is the one which
is know during "CMake configuration step".

You cannot do that this way with .deb or .rpm because you don't know the
"actual" prefix that will be in the package
because it is controlby CPACK_PACKAGING_INSTALL_PREFIX  "at CPack time",
i.e. when CPack runs.

It's even worse because .deb or .rpm may be relocated see e.g.:
https://www.cyberciti.biz/faq/howto-install-rpm-package-into-another-directory/

When you want to install script that should know where things get installed
you have 3 options:

1) Assume the binary executable is installed in the path
thus call the executable as-is "vpnserver" without absolute path

2) Put a pre- or post- install script that will compute the appropriate
path
   **during package installation** when you are sure what the real path
will be.
   Have a look at CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA in
https://cmake.org/cmake/help/latest/cpack_gen/deb.html
or
https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE

3) Ensure that you generate package with
   CMAKE_INSTALL_PREFIX == CPACK_PACKAGING_INSTALL_PREFIX
   This is ok but will break if the installation of the package is
relocated.

1) may be ok.
2) need a little work but is the more robust
3) may be enough but prevent relocatable install

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] how to debug CPack creation

2018-10-20 Thread Eric Noulard
Le sam. 20 oct. 2018 à 10:54, Илья Шипицин  a écrit :

>
>
> сб, 20 окт. 2018 г. в 13:30, Eric Noulard :
>
>>
>>
>> Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a
>> écrit :
>>
>>> hi,
>>>
>>> we use cmake/cpack for mangling systemd scripts
>>>
>>>
>>> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>>>
>>> what happens:
>>>
>>> (*) deb installs files to /usr/libexec
>>> (*) cmake sets location as /usr/local/libexec
>>>
>>
>> It looks like your get default "/usr/local" prefix from somewhere.
>>
>
> exactly.
>

So I I understand it well (correct me if I'm wrong) when you do:

1) make install
You get all installed files prefixed by /usr/local
which is the expected behaviour unless you configure
CMAKE_INSTALL_PREFIX
or you use
DESTDIR=/your/prefix make install

2) deb created by CPack get "/usr" prefix instead
   which is the expected behaviour unless you specify an alternate value
using
   CPACK_PACKAGING_INSTALL_PREFIX

go to your build tree and try:
cpack -G DEB -D  CPACK_PACKAGING_INSTALL_PREFIX=/opt

and you'll see that the .deb will have /opt prefix.

The question is what do expect as a prefix?
/usr/local
/usr
something else ??

The rules are the following when using install rule.
1) if your DESTINATION is a relative path then it will be prefix with
   CMAKE_INSTALL_PREFIX when doing make install
   CPACK_PACKAGING_INSTALL_PREFIX when building package with CPack

2) if your DESTINATION is "absolute" like /etc/whatever/confdir
It'll get install there when doing make install (whatever the value of
CMAKE_INSTALL_PREFIX)

With CPack, it depends on the generator.
   Some generators (like DEB a,nd RPM) try to catch "absolute" install file
and handle them
   as config file. RPM generator is more verbose about it see below.

Is the RPM containing what you expect?
>>
>
> I did not check it yet.
>

I tried using:
$  cpack -G RPM

and you get expected warning about the mix of absolute and relative install
path:
CPack: Create package using RPM
CPack: Install projects
CPack: - Install project: SoftEtherVPN
CPack: -   Install component: vpnserver
CPack: -   Install component: vpnclient
CPack: -   Install component: vpnbridge
CPack: -   Install component: vpncmd
CPack: Create package
CMake Warning (dev) at
/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:135
(message):
  CPackRPM:Warning: Path /lib/systemd/system/softether-vpnbridge.service is
  not on one of the relocatable paths! Package will be partially
relocatable.
Call Stack (most recent call first):

/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:1001
(cpack_rpm_prepare_relocation_paths)

/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:1870
(cpack_rpm_generate_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

[...]

CPack: - package: []/build/softether-vpnbridge-5.1.9660-1.x86_64.rpm
generated.
CPack: - package: []/build/softether-vpnclient-5.1.9660-1.x86_64.rpm
generated.
CPack: - package: []/build/softether-vpncmd-5.1.9660-1.x86_64.rpm generated.
CPack: - package: []/build/softether-vpnserver-5.1.9660-1.x86_64.rpm
generated.

And the content is:
$ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/softether-vpnserver.service
/usr/libexec
/usr/libexec/softether
/usr/libexec/softether/vpnserver
/usr/libexec/softether/vpnserver/hamcore.se2
/usr/libexec/softether/vpnserver/vpnserver
/usr/local
/usr/local/bin
/usr/local/bin/vpnserver

the content of the .deb is similar:
$ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/system/
-rw-r--r-- root/root   700 2018-10-20 14:45
./lib/systemd/system/softether-vpnserver.service
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/softether/
drwxr-xr-x root/root 0 2018-10-20 14:45
./usr/libexec/softether/vpnserver/
-rw-r--r-- root/root   1770716 2018-10-20 14:45
./usr/libexec/softether/vpnserver/hamcore.se2
-rwxr-xr-x root/root   2088960 2018-10-20 14:45
./usr/libexec/softether/vpnserver/vpnserver
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/bin/
-rwxr-xr-x root/root72 2018-10-20 14:45 ./usr/local/bin/vpnserver

The main question is, what filesystem layout do you expect for those files?

-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-t

Re: [CMake] how to debug CPack creation

2018-10-20 Thread Eric Noulard
Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a écrit :

> hi,
>
> we use cmake/cpack for mangling systemd scripts
>
>
> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>
> what happens:
>
> (*) deb installs files to /usr/libexec
> (*) cmake sets location as /usr/local/libexec
>

It looks like your get default "/usr/local" prefix from somewhere.
The installation prefix of CPack is controlled by the
https://cmake.org/cmake/help/latest/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
variable.
Each CPack generator has a default value for that (if you don't specify it).

How do run cpack?
Do you do "make package" or do you run
cpack -G DEB

Which version of cmake/cpack are you using?


> as a result: it does not work (systemd cannot find executable)
>
> https://gitlab.com/chipitsine/SoftEtherVPN/-/jobs/110262386
>
> I enabled "set(CPACK_DEBIAN_PACKAGE_DEBUG ON)", but it did not provide me
> a clue.
>

DEB generator is not as verbose as I thought.

Do you generate RPM as well? RPM is more verbose and leaves you log file in
_CPack_Packages//RPM/

Is the RPM containing what you expect?

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Detailed graphviz graph?

2018-10-07 Thread Eric Noulard
Le sam. 6 oct. 2018 à 18:15, Jan Wielemaker  a écrit :

> On 03/10/18 09:53, Eric Noulard wrote:
> >
> > Are those three add_custom_xxx in the same directory?
> > DEPENDS for custom_xxx do not cross directory.
>
> So this was not the problem. The problem was that on the Mac I had build
> the system before using the autoconf/make suite, which had created
> `swipl.prc` in the source tree. Now, this is the second time I've been
> fooled by this:
>

Good to know you've found the issue.


> If a custom command has a DEPENDS, this points at the
> CMAKE_CURRENT_SOURCE_DIR if the file exists there and at the
> CMAKE_CURRENT_BINARY_DIR otherwise.  This makes sense, but
> easily leads to things that are hard to figure out ...
>

I've already been bitten by that kind of issue.
Now when I want to be "extra-sure" of my source/build tree state I:

- remove the build tree completely
- use the VCS at hand to clean the source tree, e.g. with git
  git -fdx being in the root source dir should remove all non versioned
files (or directories) including ignore ones.
(there are more interesting feature to git-clean:
https://git-scm.com/docs/git-clean)

Then you can be sure to have a "clean" starting point.
Alternatively checking out the project in a separate place works as well.

Thanks. In particular for pointing at Ninja's tools for figuring out
> dependencies.
>

You are welcome.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

2018-10-04 Thread Eric Noulard
Le jeu. 4 oct. 2018 à 18:59, Marc CHEVRIER  a
écrit :

> I am afraid that you cannot mix "optimized" or "debug" keywords with
> "generator expressions" because keywords handling is done during evaluation
> of command "target_link_libraries" and "generator expressions" are
> evaluated during generation.
>
> And target_link_libraries expect following pattern: [] 
> [ ...], so specifying a generator expression wrapping this breaks
> the parsing of the arguments: keyword is no longer at the beginning of the
> sequence so it is no longer  recognized as is...
>
> So, The most efficient way to work-around this problem is to transform
> your list of libraries in valid generator expressions:
>
>- INITIAL: optimized foo debug food_d
>- RESULT: $<$:foo> $<$:foo_d>
>
> For that purpose, an helper function can do the trick...
>

I agree with you Marc but I nevertheless think the handling of list in
genex has something unexpected.

See my previous example with custom target.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

2018-10-04 Thread Eric Noulard
Le jeu. 4 oct. 2018 à 18:34, Björn Blissing  a
écrit :

> Hi Andrew,
>
>
>
> That works, but as previously said. The third party find module I am using
> do not differentiate between debug and release libraries. To make matters
> even worse the keywords “optimized” and “debug” is already in the variable
> list, trying to split them will be painful.
>
>
>
> The workaround I am using right now is to have an IF-statement for the
> list option:
>
> if(${USE_FOOLIB})
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> ${FOO_LIBRARIES}
>
> )
>
> endif()
>
>
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
>  $<$:bar>
>
> )
>
>
>
> But that breaks the pattern with using generator expressions, as I do for
> the rest of my options.
>
>
>
> I don’t know if this should be considered a bug, but it seems really
> strange that generator expressions should break down for only this special
> case, i.e. the combination using lists with the conditional operator BOOL
> and using it inside target_link_libraries.
>

I think you are right there is a bug.
When you put a list on the right hand-side of $>>>> cut here <<<<
cmake_minimum_required(VERSION 3.12)

project(expansion_error LANGUAGES CXX)
add_executable(my_exe main.cpp)

option(USE_ANYLIB "Use foo.lib" ON)
option(USE_BARLIB "Use bar.lib" ON)

list(APPEND ANY_LIBRARIES any1 any2)

target_link_libraries(my_exe
PUBLIC
 $<$:"${ANY_LIBRARIES}">
 $<$:bar>
)

add_custom_target(ShowMe
COMMAND ${CMAKE_COMMAND} -E echo
$<$:${ANY_LIBRARIES}>
COMMAND ${CMAKE_COMMAND} -E echo $<$:bar>
VERBATIM
)
>>>>>>>>> cut here <<<<<<<<<<<<<

then:
$ make ShowMe

gives:
$<1:any1 any2>
bar
which seems wrong too.

In the TLL you get "$<1:any1 -lany2>" in either Makefile or ninja generator
whereas you get proper "-lbar"

I don't know why this happen but it really looks like a bug.


>
>
> I don’t know if other CMake functions will react similarly bad to the
> list/bool operator combo.
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller 
> *Sent:* Thursday, October 4, 2018 6:16 PM
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist 
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What about this:
>
>
>
>
> list(APPEND FOO_LIBRARIES_OPT foo)
> list(APPEND FOO_LIBRARIES_DBG foo_d)
>
> target_link_libraries(my_exe
>PUBLIC
> debug "$<$:${FOO_LIBRARIES_DBG}>"
> optimized "$<$:${FOO_LIBRARIES_OPT}>"
> "$<$:bar>"
> )
>
> A little more verbose.
> --
>
> *From:* Björn Blissing 
> *Sent:* October 4, 2018 9:00:28 AM
> *To:* Andrew Fuller; Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* RE: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Andrew,
>
>
>
> When I put the genex inside double quotes I get:
>
> optimized.lib;foo.lib;debug.lib;foo_d.lib;bar.lib; --- for both debug and
> release builds
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller 
> *Sent:* Thursday, October 4, 2018 5:54 PM
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist 
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What happens if you put the genex inside double quotes?
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
>  "$<$:${FOO_LIBRARIES}>"
>
>  "$<$:bar>"
>
> )
>
>
> --
>
> *From:* CMake  on behalf of Björn Blissing <
> bjorn.bliss...@vti.se>
> *Sent:* October 4, 2018 8:49:19 AM
> *To:* Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Eric,
>
>
>
> I tried to do a self contained minimal example:
>
>
>
> cmake_minimum_required(VERSION 3.12)
>
> project(expension_error LANGUAGES CXX)
>
>
>
> add_executable(my_exe main.cpp)
>
>
>
> option(USE_FOOLIB "Use foo.lib" ON)
>
> option(USE_BARLIB "Use bar.lib" ON)
>
>
>
> list(APPEND FOO_LIBRARIES optimized foo)
>
> list(APPEND F

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

2018-10-04 Thread Eric Noulard
Le jeu. 4 oct. 2018 à 16:53, Björn Blissing  a
écrit :

> Hello Eric,
>
>
>
> The minimal example was just to display the expansion error. In real life
> the code uses a Boolean variable (and the rest of the CMake code is much
> larger as well).
>
It was just to show the expansion error you get if you try to use a
> conditional generator expression inside a target_link_libraries function.
>

Sometimes the devil is hiding in the details.
Do ou manage to reproduce the genex expansion error on a toy example?


> I do agree that using it would be simpler if I could use:
>
>  $<$:${MYLIBS_DEBUG}>
>
>  $<$:${MYLIBS_OPTIMIZED}>
>
>
>
> But since I use a third party find module the MYLIB_LIBRARIES variable is
> not separated into these categories. I was hoping to avoid rewriting this
> external find module.
>

You can perfectly write a CMake helper function which takes MYLIB_LIBRARIES
as input and spit out MYLIBS_DEBUG, MYLIBS_OPTIMIZED as an output.
This way you don't have to rewrite 3rd party code and keep your code clean.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

2018-10-04 Thread Eric Noulard
Le jeu. 4 oct. 2018 à 16:06, Björn Blissing  a
écrit :

> Hello,
>
>
>
> I am having trouble with a conditional generator expression inside target
> link libraries, which seems to expand incorrectly (or at least not the way
> I expect).
>
>
>
> In short, I have a list of libraries that is found by a CMake module. The
> list is composed of a number of elements each preceded by “optimized” or
> “debug”, depending on if there are built for release or debug. These
> libraries should only be included if a boolean is set to true. I have tried
> to write a generator expression which only includes the list of libraries
> if this variable is set. But it seems that this expression gets expanded
> wrong.
>
>
>
> If I try to condense the problem to a minimum example, it would be
> something like this:
>
>
>
> LIST(APPEND MYLIB_LIBRARIES optimized foo)
>
> LIST(APPEND MYLIB_LIBRARIES debug foo_d)
>
>
>
> TARGET_LINK_LIBRARIES(target_name
>
> PUBLIC
>
> $<$:${MYLIB_LIBRARIES}>
>
> )
>

I don't quite understand your usage here. The genex $ is always
true?
You must have something like:

$<$:${MYLIB_LIBRARIES}>

with CONDVAR computed before that to HOLD TRUE/1 or FALSE/0
or something similar?

I would try to build a proper MYLIBS_DEBUG and MYLIBS_OPTIMIZED list out of
your MYLIB_LIBRARIES var

and then:

target_link_libraries(target_name
   PUBLIC
 $<$:${MYLIBS_DEBUG}>
 $<$:${MYLIBS_OPTIMIZED}>

which may be easier to read.

Or may be I missed something in your explanation.


>
> This generator expression makes my target depend of the following
> libraries for the release build:
>
> foo.lib & optimized.lib
>
>
>
> And for the debug build:
>
> foo_d.lib, foo.lib & optimized.lib
>
>
>
> Which is obviously incorrect.
>
>
>
> Replacing the generator expression with an IF-statement instead works. But
> I would like to stick to generator expressions if possible to keep my CMake
> code consistent.
>
>
>
> How should I rewrite my generator expression to get the correct expansion?
>
>
>
> Regards,
>
> Björn
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Detailed graphviz graph?

2018-10-03 Thread Eric Noulard
Le mer. 3 oct. 2018 à 09:19, Jan Wielemaker  a écrit :

> Hi,
>
> Debugging dependencies is not always easy.  The -graphviz option is a
> nice try, but only seems to do the built-in target types.  Is there
> some way to get the whole dependency graph, including custom targets
> and possibly also the individual files?


Not yet I guess:

https://gitlab.kitware.com/cmake/cmake/issues/17960


> Of course this can get huge.
> Possibly there is some way to concentrate on anything relevant to a
> particular target?
>

Besides the custom target issue. I did craft a python script which loads
the dependency graph spitted out by CMake
and do various thing on it:

- search if there exist a path between two targets
- find all path between two targets
- reduce the graph (transitive closure)
etc...

If you use ninja Generator you may try the browse or graph
extra tool:
https://ninja-build.org/manual.html

This is generator specific and it may be difficult to follow your
"original" CMake target in the generated ninja version.


The problem I'm faced with is this:
>
>- I have an ordinary executable target `swipl`
>- To run, this requires a boot file `swipl.prc` that is created
>  by calling `swipl -b ...`
>

Hum... I don't get it.
For running? creating? target "swipl" you need to run it?
There is a chicken & eggs problem or I misread what you said?


>- I'd like to run `swipl` for creating a library index file.
>
> So, these targets need to be built in the order above.  It turns
> out that sometimes step 3 runs before 2 completes.  At least, this
> happens on MacOS using cmake 3.11.2.  So far I haven't seen it on
> Linux (where I use 3.10).  The definition goes like this:
>
> add_custom_command(
>  OUTPUT  swipl.prc
>  COMMAND swipl -O -b ${SWIPL_BOOT_ROOT}/init.pl
>  DEPENDS swipl ${SWIPL_BOOT_FILES}
> )
>
> add_custom_command(
>  OUTPUT  ${PL_LIB_INDEX}
>  COMMAND swipl -f none -g
> "\"make_library_index('${SWIPL_LIBRARY_ROOT}')\"" -t halt
>  DEPENDS swipl.prc ${PL_LIB_FILES_ALL}
> )
>
> add_custom_target(prolog_products ALL
>  DEPENDS swipl.prc ${PL_LIB_INDEX}
> )
>
> The first specifies building swipl.prc, the second the index
> file and the custom target ensures the default build will
> create both files.  I don't see what is wrong and a visual
> dependency graph might reveal this ...
>

Are those three add_custom_xxx in the same directory?
DEPENDS for custom_xxx do not cross directory.

i.e:
``DEPENDS``
  Reference files and outputs of custom commands created with
  ``add_custom_command()`` command calls in the same directory
  (``CMakeLists.txt`` file).  They will be brought up to date when
  the target is built.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Making variables visible in ccmake

2018-09-28 Thread Eric Noulard
Le ven. 28 sept. 2018 à 13:03, Dorier, Matthieu  a écrit :

> Ah then maybe I don't understand correctly what is supposed to be
> displayed by ccmake.
>

My usage workflow, not sure it is the expected one but other CMake
users/developers may correct me if my usage is wrong.

1) Launch ccmake in an empty buiddir :
ccmake -G Ninja /path/to/source

2) Hit 'c' once to populate the cache

3) hand edit needed var

4) Hit 'c' again and check result

5) Hit 'g'.

Then I may have forgotten to toggle an option so I :

1) Launch ccmake in the populated build dir:
ccmake .

2) hand edit the forgotten vars

3) Hit 'c' then 'g'.



> In general, how can I have in the ccmake screen some variables displayed
> to configure some paths to some libraries?
>

You have to hit 'c' once to populate the cache and make ccmake/cmake-gui
aware of the defined (may be void) variables/

There was a "wizard" mode for cmake some time ago that was asking questions
for setting var values but it's gone:

$ cmake -i
The "cmake -i" wizard mode is no longer supported.
Use the -D option to set cache values on the command line.
Use cmake-gui or ccmake for an interactive dialog.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Making variables visible in ccmake

2018-09-28 Thread Eric Noulard
Le ven. 28 sept. 2018 à 11:59, Dorier, Matthieu  a écrit :

> Hi,
>
>
> How do I make a variable visible in the ccmake tool?
>
> For example I would like the user to be able to edit BOOST_ROOT when
> calling ccmake, how can I do that?
>
>
> Right now all I see when first running ccmake is "EMPTY_CACHE", and when
> typing "c" to configure (which fails because some variables aren't properly
> set) then "e" to exit, I see the variables I have defined with "option",
> and I can toggle those, but I don't see other variables. I have tried the
> following:
>
>
> if(NOT DEFINED BOOST_ROOT)
>   set(BOOST_ROOT "/usr" CACHE PATH "Root of the Boost installation")
> endif(NOT DEFINED BOOST_ROOT)
>
>
> But I still don't see it in the list of variables.
>

CACHE variables are "Advanced Variables" which are not displayed unless you
toggle display advanced var in either ccmake or cmake-gui.
In ccmake you have to hit 't' in order to see advanced variables.


>
> Additionally, is there a way to have set of variables (namely the options,
> as well as things like BOOST_ROOT, CMAKE_CXX_COMPILER, CMAKE_C_COMPILER)
> show up when first calling ccmake, instead of EMPTY_CACHE?
>

I don't know, CMAKE__COMPILER is not meant to be set with cmake UI,
they ought to be set in a toolchain or outside.
As noted in CMakeForceCompiler module you should not force them, use
toolchain or env var before calling cmake* tool.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake Cookbook is out!!

2018-09-28 Thread Eric Noulard
Le jeu. 27 sept. 2018 à 23:49, Alan W. Irwin  a
écrit :

> On 2018-09-27 20:26+0200 Eric Noulard wrote:
>
> > Hi CMakers,
> >
> > Hi try not do that too often but here comes a little promotion for a book
> > which (I think) deserve attention.
> > The CMake Cookbook by Radovan Bast, Roberto Di Remigio
> > https://www.packtpub.com/application-development/cmake-cookbook
>
> I don't buy e-books unless they are DRM-free. (See <
> https://en.wikipedia.org/wiki/Digital_rights_management#Opposition> for
> why DRM is such a concern to knowledgable readers of e-books.)
>

Hi Alan,

I'm am well aware of the DRM plague However I shall admit that for this
time I didn't checked before accepting the book review because I was
pleased to help people do what I didn't manage to do myself: write a CMake
book.

I know both authors now and I'm pretty sure they don't want to put any
knowledge in a cage.


> Thus, I was very happy to see the e-book form of the above book is
> DRM-free.
>

Yes precisely and the reason is a clear no go for DRM on the publisher side:
https://hub.packtpub.com/packt-and-day-against-drm/

Don't take my words as bare advertisement but as enthusiasm for freedom.
Next exchange on this off-topic will go off the CMake Mailing List.
-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] CMake Cookbook is out!!

2018-09-27 Thread Eric Noulard
Hi CMakers,

Hi try not do that too often but here comes a little promotion for a book
which (I think) deserve attention.
The CMake Cookbook by Radovan Bast, Roberto Di Remigio
https://www.packtpub.com/application-development/cmake-cookbook

I'm not the author but I participate in the book review and I think the
authors did a great job and the book contains a lot of good stuff for CMake
users.

There is companion github project:
https://github.com/dev-cafe/cmake-cookbook/
which contains all the recipes of example of code  used in the book.
All the recipes are tested to various CI in order to ensure they work as
expected.

Happy building for everyone.
-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] --config Parameter position relevant?

2018-09-19 Thread Eric Noulard
Le mer. 19 sept. 2018 à 13:43, Dennis Luehring  a écrit :

> build environment:
>
> Win7 x64
> VStudio 2017 Community Edition 15.8.4 (latest)
> CMake 3.12.1 (x86)
> git 2.19.0 (latest, x64)
> Python 2.7.2 (x86)
>
> directory structure:
>
> D:/projects/fun/jit_tests/clang_from_src/
>llvm <-- git clone https://github.com/llvm-mirror/llvm
>  tools
>clang <-- git clone https://github.com/llvm-mirror/clang
>llvm_build
>
> build instructions:
>
> cd llvm-build
> cmake -Thost=x64 -G "Visual Studio 15 2017 Win64"
> -DLLVM_TARGETS_TO_BUILD=host ..\llvm_project\llvm
>
> cmake --config Release --build .
>
> ends after a few seconds without errors with this message last
>
> Build files have been written to:
> D:/projects/fun/jit_tests/clang_from_src/llvm-build
>
> cmake --build . --config Release
>
> do work and the build is running - is it intended that the position of
> the --config parameter is that relevant?


I guess it is because --config is a sub-option of the --build option whose
expected syntax is:
cmake --build  [options] [-- [native-options]]

In the other case the expected syntax is different:
cmake [options] 

See the different expected syntaxes of the cmake command line here:
https://cmake.org/cmake/help/latest/manual/cmake.1.html

That said the "non working" case should probably at least warn about
ignored/unused options on the command line.
However, I suspect that maintaining backward compatible command line
behavior while providing meaningful
error messages may not be easy.

CMake developers may give more precise answer on that "guess".

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-12 Thread Eric Noulard
Le mar. 11 sept. 2018 à 22:09, Michael Jackson 
a écrit :

> I add it manually each and every time. I have to tell all new developers
> to remember to add the flag otherwise they are still sitting after an hour
> waiting on our code to compile wondering why it takes so long. Then it hits
> us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at the
> situation but not sure how to fix it. I tried the other suggestions and
> just nothing works. This is one of those things that I poke at once a year
> and figure out that nothing has changed. Been this way since VS 2013.
> Someday it will change.
>

I don't know your constraint on using msbuild but if the "main" issue is to
automatically exploit parallel build did you try to switch to ninja instead
of msbuild?

Visual C++ Tools for CMake seems to  [begin to] support that path as well:
https://blogs.msdn.microsoft.com/vcblog/2017/05/10/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Problems with static jpeg library

2018-09-11 Thread Eric Noulard
Le mar. 11 sept. 2018 à 16:10,  a écrit :

> Hi,
>
> thank you for your reply. I could solve the problem. The part I didn't
> knew was that static libraries also needed to be compiled with -fPIC.
> I've found a good summary of this topic at
> https://lists.debian.org/debian-devel/2016/05/msg00309.html
> I want to share it for those, who also stumble upon this problem.
>


And for project using CMake as build system one can use,
POSITION_INDEPENDENT_CODE
target property:
https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html#prop_tgt:POSITION_INDEPENDENT_CODE
or globally:
https://cmake.org/cmake/help/latest/variable/CMAKE_POSITION_INDEPENDENT_CODE.html#variable:CMAKE_POSITION_INDEPENDENT_CODE

in order to enable such flags.



>
> On 2018-09-11 13:47, Rolf Eike Beer wrote:
> > wo...@masterdevops.eu wrote:
> >> Hi,
> >>
> >> I am trying to compile the project libgd
> >> (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled.
> >>
> >> I.e. first I downloaded the source code of libjpeg-turbo from
> >> https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled
> >> it
> >
> > You need to make sure that this compile includes -fPIC in the
> > compileflags of
> > libjpeg.
> >
> >> But I get several errors like this one:
> >> > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o):
> >> > relocation R_X86_64_32S against `.text' can not be used when making a
> >> > shared object; recompile with -fPIC
> >
> > As said here.
> >
> > Eike
> > --
>
> --
> German DevPos site: https://www.masterdevops.eu
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] overriding -03 -DNDEBUG Release flags

2018-09-10 Thread Eric Noulard
Le lun. 10 sept. 2018 à 14:34, Stéphane Ancelot 
a écrit :

> Hi,
>
> In one project I need to compile with -O2 option , how to set it and
> remove -O3 -DNDEBUG flags for this project ?
>

May be you can create a new Build Type with appropriate flags:
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-extend-the-build-modes-with-a-custom-made-one-

and set it as the default build type for this particular project?
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-change-the-default-build-mode-and-see-it-reflected-in-the-gui
https://blog.kitware.com/cmake-and-the-default-build-type/


> --
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] unknown cmake command

2018-09-09 Thread Eric Noulard
Le dim. 9 sept. 2018 à 06:52, Robert Finch  a écrit :

> Hi, cmake is new to me. I’m attempting to use cmake to build a backend for
> LLVM. CMake fails with an ‘unknown cmake command’ error. It doesn’t seem to
> be able to find or execute modules or macros. I tried setting the
> CMAKE_MODULE_PATH, LLVM_CMAKE_DIR, LLVM_DIR, and LLVM_TABLEGEN variables. I
> wonder if this would be a problem spawning executables ? Security ? Nothing
> is written to the log file. tablegen is in the path and can be run
> manually, but cmake fails to run it. Cmake successfully built and installed
> LLVM.  The file cmake fails with is Cmakelists.txt. The OS is Windows 10
> pro build 1803.
>

If the project is public is would be easier to help you if you point out
the repo of the project.
You should at least provide the full CMake error message your are getting
along with CMake version and CMake generator you use (VIsual Studio,
etc...)

I do build LLVM/clang and some tooling which are not bundled with it like
IWYU (https://include-what-you-use.org/) it appears that LLVM has specific
CMake macros that ought to be used in the right way. e.g. for IWYU
something different is done if it's built in-source (along with LLVM+clang
source tree) or out-of-source.You may have a look at:
https://github.com/include-what-you-use/include-what-you-use/blob/master/CMakeLists.txt
to see what they do for that.

However from (https://llvm.org/docs/WritingAnLLVMBackend.html#preliminaries)
I bet that building a backend is very different from building a clang-based
extra tool.
Did you get in touch on some LLVM mailing list about that?

I bet your issue may be more related on "how to use LLVM cmake build
system" than  a generic CMake issue.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Specify extra files for display in IDE

2018-09-05 Thread Eric Noulard
Le mer. 5 sept. 2018 à 11:00, Daniel Eiband  a
écrit :

> Hi,
>
>
>
> I managed to solve the presentation of object libraries by renaming the
> targets and hiding certain targets in folders. I think this solution is
> acceptable.
>
>
>
> The issue with the display of header only libraries in IDEs, which are
> implemented as interface libraries, is still unsolved. The add_library()
> command doesn’t accept any sources.
>

For an interface library you can add sources with

target_sources(yourlib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)

You need the INTERFACE keyword though:
https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries

is this not working for you?

Could you provide a strip-down archive which exhibit this issue I may try
it on my side?


> Also setting the SOURCES property of an interface library target is
> rejected by CMake.
>

This is because you can only populate INTERFACE_SOURCES on an INTERFACE
target:
https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_SOURCES.html
https://cmake.org/cmake/help/latest/command/target_sources.html#command:target_sources



> I haven’t found any other way of adding the files to the interface library
> so that they are presented in the IDE.
>

Like I said in a previous email on my side, interface library (INTERFACE)
sources are displayed in vscode and qtcreator, may be the fact that they
are not displayed by Visual Studio
is a Visual Studio bug?

By the way there is an old issue on this subject:
https://gitlab.kitware.com/cmake/cmake/issues/15234



> I know the workaround of adding an empty custom target. This is however
> not really satisfying, because Visual Studio for example displays them with
> a completely different icon and the suffix “(utility target)”. Doesn’t look
> like a C++ library any longer. It also sort of highlights the library
> because of the non-C++ icon and I have to hide even more targets (the real
> interface libraries).
>
>
>
> From a CMake interface perspective this is also an asymmetry: Why can I
> add arbitrary files to executable and static/shared library targets being
> displayed in IDEs without contributing to the build artifact while this is
> not possible for interface libraries? I think, the restriction on interface
> libraries should not be that they don’t have any source files. Interface
> libraries must not have source files which produce build artifacts.
>

Agreed and I think it would more "natural" to be able to simply
target_sources / add_library "as usual" and promote SOURCES to
INTERFACE_SOURCES automatically since the target is an INTERFACE lib.


>
> Is this worth an enhancement bug or has this already been discussed?
>

The only one I am aware of is this one:
https://gitlab.kitware.com/cmake/cmake/issues/15234

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] creating a library from other one

2018-08-31 Thread Eric Noulard
Le ven. 31 août 2018 à 15:59, Stéphane Ancelot  a
écrit :

> I ended with :
>
> add_custom_target(combined ALL
>COMMAND ${CMAKE_AR} rc libcombined.a $ $ FILE:lib2>)
>

Quick & dirty :-)
There is the "thin" option of ar as well:
https://stackoverflow.com/questions/3821916/how-to-merge-two-ar-static-libraries-into-one
if you know the content of lib1 and lib2 don't have name clash.

However libcombined.a is not a proper library target for CMake now.

And by the way does this work on Window too ? Or may be you don't care ?



-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] creating a library from other one

2018-08-31 Thread Eric Noulard
First create OBJECT libraries instead of static
Then create as many STATIC libraries as you want that includes as many
OBJECT libraries content as you want.


Le ven. 31 août 2018 à 15:17, Stéphane Ancelot  a
écrit :

> Hi,
>
> I have got some static libraries generated, that  I would like to put in
> a common one.
>
> how can I proceed ?
>
> Regards,
>
> S.Ancelot
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] find_package with COMPONENTS never honors REQUIRED

2018-08-30 Thread Eric Noulard
Le jeu. 30 août 2018 à 20:03, George PF  a écrit :

> > The documentation is intriguing about REQUIRED COMPONENTS interaction
>
> That's... one way to put it.
>

Yeah you know. Kind of ironic here :-)


> > So it is possible that the failure behavior when specifying COMPONENTS
> is up to the module...
>
> I admit I was not reading the docs in that depth, but REQUIRED can only
> mean one thing and should
> not need second guessing the documentation. Sadly, someone thought
> otherwise.
>

I guess there is no one to blame here.
The doc is too-realistic about the state of find modules.
At least Config mode should do it right I hope.
Module mode is historically for hand-written module maintained by
volunteers:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/dev/Module-Maintainers

> Do you see this only with Qt or do other packages with components (may be
> Boost) behave like this?
> > I guess that Qt5 should be running in config mode, whereas boost must be
> in module mode though.
>
> I was debugging an older cmake project and wondered why it was not finding
> the non-standard Qt location,
> that's when I stumbled upon this issue.
>

I see. I think something could/should be done for Config mode, for Module
mode It would certainly depends on the module maintainer.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] find_package with COMPONENTS never honors REQUIRED

2018-08-30 Thread Eric Noulard
Le jeu. 30 août 2018 à 18:01, George PF  a écrit :

> Hi,
>
> once COMPONENTS is added to a find_package statement, any REQUIRED
> statement ceases to have an effect:
>
> cmake_minimum_required(VERSION 3.12)
>
> # find_package(FailsCorrectly REQUIRED)
>
> find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS  Qt5XYZ )
> find_package(Qt  COMPONENTS REQUIRED Qt5XYZ )
> find_package(Qt  COMPONENTS  Qt5XYZ REQUIRED)
> find_package(Qt  COMPONENTS REQUIRED Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS  Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ )
>
>
> This CMakeLists.txt runs, despite Qt5XYZ not existing. How can this be
> made to fail as it should, why
> else would there be OPTIONAL_COMPONENTS as well?
>

The documentation is intriguing about REQUIRED COMPONENTS interaction

"A package-specific list of required components may be listed after the
``COMPONENTS`` option (or after the ``REQUIRED`` option if present).
Additional optional components may be listed after
``OPTIONAL_COMPONENTS``."

and

"Available components and their influence on
whether a package is considered to be found are defined by the target
package."

and later on:

"In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
``[version]`` options automatically but leaves it to the package
configuration file to handle components in a way that makes sense
for the package.  The package configuration file may set
``_FOUND`` to false to tell ``find_package`` that component
requirements are not satisfied."

So it is possible that the failure behavior when specifying COMPONENTS is
up to the module...

Do you see this only with Qt or do other packages with components (may be
Boost) behave like this?
I guess that Qt5 should be running in config mode, whereas boost must be in
module mode though.

By the way for Qt5 the doc says you shouldn't be using find_package(Qt):
https://cmake.org/cmake/help/latest/module/FindQt.html

But probably directly:
find_package(Qt5)

see example here: https://blog.kitware.com/cmake-finding-qt5-the-right-way/
-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Specify extra files for display in IDE

2018-08-30 Thread Eric Noulard
Le jeu. 30 août 2018 à 12:32, Daniel Eiband  a
écrit :

> Hi,
>
>
>
> I’m currently migrating a code base from a proprietary MSBuild based
> generator to CMake 3.11 which is shipped with Visual Studio. There are two
> aspects to this task:
>
>
>
> 1) Integration of custom build steps
>
> 2) Presentation in the IDE
>
>
>
> The first aspect of integrating all of our custom build steps as custom
> commands works really well. At one point I use an object library to be able
> to use the object files as input to such a custom tool and to link a shared
> library. Both the object library and the shared library are from the
> programmers perspective one logical unit. The object library is just an
> implementation detail. However, as for the second point, the source files
> are displayed with the object library target in the IDE while the shared
> library has no sources. This makes sense from the build targets point of
> view, but surprises the developers.
>
> My approach is to hide all targets which are sort of implementation detail
> into a folder.  To make this work I would like to display the sources with
> the shared library which consumes the object files of the object library.
> Currently this seems to be impossible.
>
>
>
> Another inconsistency I noticed regarding the second point is the
> following: I implemented header only libraries as interface libraries in
> CMake. This works fine from the build perspective. Interface libraries
> however don’t allow me to list sources, not even headers. As a result, the
> headers of this header only library are not displayed anywhere in the IDE.
> This is odd, because in executable targets for example I can list all
> headers even if they don’t contribute to the build process directly and
> they are displayed in the IDE. Using empty custom targets to present the
> header files works, but they are not displayed as C++ libraries in Visual
> Studio any longer. This also litters the solution with lots of extra empty
> targets.
>
>
>
> I’m going to rephrase both described presentation problems into one more
> fundamental question, solutions or workarounds for either of both
> presentation problems are of course welcome: Can I specify sources used for
> builds and files used for display in IDEs separately? I think they are two
> different things. For my use case it would also be sufficient to be able to
> add extra files for display in IDEs to any target.
>

I'm afraid that your question may be generator-specific and I'm no sure
Visual Studio generator behaves in the same way as others I'm using.
I do very often add non source file (like README.md) to any targets
(add_executable, add_library, add_custom_target) in order to make them
editable in the IDE.
Since those file are guessed as not being compilable they inherit the
HEADER_FILE_ONLY  (
https://cmake.org/cmake/help/v3.11/prop_sf/HEADER_FILE_ONLY.html)
automatically
and they show up in IDE just fine.

My particular IDE being either qtcreator, vscode+cmaketools or eclipse and
this works well for those.

Moreover, in qtcreator (for example) header only libraries appear on their
own with editable header file AND as subdir of every other targets their
are used by. This subdir contains the headers.
This is not the case with object libraries though :-(

Concerning the visual grouping you must already being using source_group (
https://cmake.org/cmake/help/latest/command/source_group.html) source_group
does not seems
to have any effect in my favorite IDEs...

In the end I don't know if there is currently any ways to do what you want.

At least the "never displayed" header only library looks like a bug of the
Visual Studio generator to me.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

2018-08-29 Thread Eric Noulard
Le mer. 29 août 2018 à 14:44, George PF  a écrit :

>
> >
> > My opinion (but I may be proven wrong by others) is that genex contains
> > generator specific bits that cannot be **evaluated**
> > until the build system is generated.  Properties (on target, or
> directory,
> > or files) contains informations that is available as soon
> > as the corresponding CMakeLists.txt part defining the object has been
> > processed.
>
> That seems more like an internal cmake limitation. Though maybe on purpose
> so
> the scripts can not be tailored for just one backend.
>

I think this was a design choice thus the name "Generator" expression they
are evaluated at generation time
not configuration time and I don't think it's an internal cmake limitation,
I think (but I may be wrong) that this
"generation step" would happen for any generative build system.

And there is more than that about "when" you'll know some var values.
Some generators are supporting "multiple build configuration" like MSVC and
Xcode so that
the build output dir is "mangled" with a prefix **at build time** (since
you can switch configuration after you have generated your project files).
see e.g.
https://cmake.org/cmake/help/latest/variable/CMAKE_CFG_INTDIR.html

And the documentation says quite optimistically: "Generator expressions are
> allowed
> in the context of many target properties", a more restrictive phrasing -
> "only works
> with X / Y for reasons Z" would help there.


I agree this could be clearer.
Having a possibly exhaustive description of where genex may be used would
be nice.
May be it's worth a bug report with a proposal doc update?

Genex support is added in places where it is useful (and possible I guess):
https://gitlab.kitware.com/cmake/cmake/issues/15374
https://gitlab.kitware.com/cmake/cmake/issues/15785

And concerning having them "at configure time", there is open issue
about "configuration expression":
https://gitlab.kitware.com/cmake/cmake/issues/17962


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via project LANGUAGE?

2018-08-28 Thread Eric Noulard
Le mar. 28 août 2018 à 19:07, Quang Ha  a écrit :

> Hi all,
>
> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
> something along the line:
>

May be you can only:

  project(foo LANGUAGES CXX)

then

include(CheckLanguage)
check_language(CUDA)
if(CMAKE_CUDA_COMPILER)
  enable_language(CUDA)
else()
  message(STATUS "No CUDA compiler found")
endif()

see doc:
https://cmake.org/cmake/help/latest/module/CheckLanguage.html


Eric


> if (CUDA_FOUND)
>   set_language_to_CUDA_and_CXX
> else(CUDA_FOUND)
>   set_language_to_CXX_only
> endif(CUDA_FOUND)
>
> The main reason is I don't want CMake to fail when CUDA compiler isn't
> available. Rather, it should continue to compile the source files using CPP
> compilers instead.
>
> Thanks,
> Quang
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

2018-08-28 Thread Eric Noulard
I cc the list because I think you drop it inadvertently.

Le mar. 28 août 2018 à 16:18, George PF  a écrit :

> > Because generator expressions are not handled in every cmake construct:
> >
> https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
> >
> > genex is probably not handled in foreach.
>
> That is a harsh limitation, set() or list() also does not expand this
> expression.
>

genex are evaluated during "Generation time" i.e. when CMake
produces/generates the specific build system
files (makefile, [build|rules].ninja, MSVC solution etc...). This is
convenient because some (most of) genex informations
may be generator specific (library file name, build artefact location,
etc...)

https://stackoverflow.com/questions/46206495/cmake-generator-expressions

set() , list(), foreach() are "running" at "CMake time" i.e. when cmake
runs and processes CMakeLists.txt and other cmake scripts
that is before "Generation time".


And the variable XYZ, when set via this indirection to TARGET_OBJECTS,
>
> add_library(lib12 SHARED $)
> get_property(XYZ TARGET lib12 PROPERTY SOURCES)
>
> is also not expanded yet. Is there a workaround regarding the generator
> expressions, or
> another way to get the TARGET_OBJECTS of an object library (and why is
> this hidden
> behind a generator and not available as a property)?
>

My opinion (but I may be proven wrong by others) is that genex contains
generator specific bits that cannot be **evaluated**
until the build system is generated.  Properties (on target, or directory,
or files) contains informations that is available as soon
as the corresponding CMakeLists.txt part defining the object has been
processed.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

2018-08-28 Thread Eric Noulard
Le mar. 28 août 2018 à 15:39, George PF  a écrit :

> Hello,
>
> how can e.g. $ be iterated over in cmake?
>
> This builds the lib, but the loop is never run:
>
> add_library(objlib12 OBJECT lib1.c lib2.c)
> foreach(o IN LISTS $)
> message("obj ${o}")
> endforeach()
>
> But the $ variable is set correctly, as this
> builds a shared library:
>
> add_library(lib12 SHARED $)
>
> And the ;-separated list is visible when running this custom command via
> the 'test12' target:
>
> add_custom_command(OUTPUT libtest.cc
> COMMAND bash -c "echo '$'; echo >
> libtest.cc"
> VERBATIM)
> add_library(test12 SHARED libtest.cc)
>
>
> Why does the for loop completely ignore this variable?
>

Because generator expressions are not handled in every cmake construct:

https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html

genex is probably not handled in foreach.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Adding an individual define to each source file of a library

2018-08-23 Thread Eric Noulard
Le jeu. 23 août 2018 à 19:18, George PF  a écrit :

> > > However, whatever I write into 'set_property()' - no APPEND, single
> entry,
> > > not quoted - does not end up
> > > on the compiler command line. Is there a type mismatch which is
> silently
> > > ignored?
> > >
> >
> > Or you are doing this in a directory which is not the one where the
> target
> > is defined and from the doc:
> > $ cmake --help-command set_property
> >
> > ...
> > ``SOURCE``
> >   Scope may name zero or more source files.  Note that source
> >   file properties are visible only to targets added in the same
> >   directory (CMakeLists.txt).
> >
> > ...
>
> This is all in the same directory, full setup and test:
>
> % cmake --version
> cmake version 3.12.0   [..]
> % mkdir mylib && cd mylib
> mylib% touch file1.c file2.c
> mylib% cat > CMakeLists.txt
>
> cmake_minimum_required(VERSION 3.12)
>
> add_library(mylib SHARED file1.c file2.c)
>
> get_property(mysrcs TARGET mylib PROPERTY SOURCES)
> foreach(x IN LISTS mysrcs)
> message("at ${x}")
> set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
>

almost there but you forgot to take value of 'x'

set_property(SOURCE ${x} APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")

works for me.





> endforeach(x)
> # ^D
>
> mylib% mkdir build && cd build && cmake ..
> [..]
> at file1.c
> at file2.c
> -- Configuring done
> [..]
> mylibs/build% grep -r TEST1 . || echo no TEST1
> no TEST1
>
> and 'make VERBOSE=1' also shows no extra -DTEST1 compiler arguments.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Adding an individual define to each source file of a library

2018-08-23 Thread Eric Noulard
Le jeu. 23 août 2018 à 18:31, George PF  a écrit :

> Thank you for the precise pointers, I added to the same CMakeLists.txt:
>
> get_property(mysrcs TARGET mylib PROPERTY SOURCES)
>
> foreach(x IN LISTS mysrcs)
> message("at ${x}")
> set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
> #set_source_files_properties(x PROPERTIES COMPILE_DEFINITIONS
> "TEST1;TEST2;") # also not working
> endforeach(x)
>
> However, whatever I write into 'set_property()' - no APPEND, single entry,
> not quoted - does not end up
> on the compiler command line. Is there a type mismatch which is silently
> ignored?
>

Or you are doing this in a directory which is not the one where the target
is defined and from the doc:
$ cmake --help-command set_property

...
``SOURCE``
  Scope may name zero or more source files.  Note that source
  file properties are visible only to targets added in the same
  directory (CMakeLists.txt).

...


> As to __FILE__ or similar, the define is used as a variable, i.e. the .c
> suffix would have to be removed
> via the c processor. The current directory is also used. I think replacing
> .c and appending the name of
> the current directory will be easier in cmake.
>
>
> > Le jeu. 23 août 2018 à 13:02, George PF  a
> écrit :
> >
> > > Hello,
> > >
> > > following "modern cmake" conventions I want to create a library where
> > > every single file is compiled with an individual define (-D_fileX_,
> > > required for a macro which integrates code into every translation
> unit).
> > >
> > > So following this
> > >
> > > add_library(mylib SHARED file1.c file2.c)
> > > target_link_libraries(mylib PUBLIC otherlib)
> > >
> > > I'd like to iterate over all "mylib" source file targets and modify
> them
> > > so that the compiler is called like this:
> > >
> > > cc -c -o file1.o file1.cc -D_file1_define_
> > > cc -c -o file1.o file2.cc -D_file2_define_
> > > etc.
> > >
> > > Is this possible?
> > >
> >
> > You can retrieve the sources associated with a target using SOURCES
> > properties.
> > https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html
> >
> > then
> > https://cmake.org/cmake/help/latest/command/foreach.html
> > with
> > https://cmake.org/cmake/help/latest/command/set_property.html
> > or
> >
> https://cmake.org/cmake/help/latest/command/set_source_files_properties.html
> >
> > for setting property:
> > https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html
> >
> > on each source file.
> >
> > not sure why you want to do that you know that compiler already defined
> > many "standard" macro for you, like __FILE__
> >
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
> > ?
> >
> > --
> > Eric
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Adding an individual define to each source file of a library

2018-08-23 Thread Eric Noulard
Le jeu. 23 août 2018 à 13:02, George PF  a écrit :

> Hello,
>
> following "modern cmake" conventions I want to create a library where
> every single file is compiled with an individual define (-D_fileX_,
> required for a macro which integrates code into every translation unit).
>
> So following this
>
> add_library(mylib SHARED file1.c file2.c)
> target_link_libraries(mylib PUBLIC otherlib)
>
> I'd like to iterate over all "mylib" source file targets and modify them
> so that the compiler is called like this:
>
> cc -c -o file1.o file1.cc -D_file1_define_
> cc -c -o file1.o file2.cc -D_file2_define_
> etc.
>
> Is this possible?
>

You can retrieve the sources associated with a target using SOURCES
properties.
https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

then
https://cmake.org/cmake/help/latest/command/foreach.html
with
https://cmake.org/cmake/help/latest/command/set_property.html
or
https://cmake.org/cmake/help/latest/command/set_source_files_properties.html

for setting property:
https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html

on each source file.

not sure why you want to do that you know that compiler already defined
many "standard" macro for you, like __FILE__
https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
?

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Problem with creating shared library

2018-08-21 Thread Eric Noulard
Le lun. 20 août 2018 à 19:05, Damir Porobic  a
écrit :

> Hi Eric,
>
>
> yes, this is the project. I have pushed my current state to this branch
> https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch
>
> I've tried also without the generate_export_headers (cleaned everything up
> before trying out) but I get the same result.
>
>
> KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the
> handwritten file, that's true, I think I got something mixed up there and I
> don't actually need the generate_export_headers, but as said, even
> without the line, it's not working.
>

I'm quite lost with the file layout.

in example/main.cpp you do:
#include 
so I guess you expect that
target_link_libraries(kImageAnnotator-example PRIVATE
kImageAnnotator::kImageAnnotator)

will bring you the include path to "kImageAnnotator/KImageAnnotator.h"
along with the [imported] target

in your main tree (not in example) there is a trick because you did:

add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)

and then in the test directory you do:

target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB)

with

add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS})

so AFAIU you compile your kImageAnnotator library twice. Once for building
the target you expect to use in example/ subdir
and another time as a STATIC lib for the unit test. So the unit test is not
linking to the same object lib at all ??

I am not used to KDE development but all this seems very fuzzy to me.

May be you could get more precise help from people who know better about
KDE dev and the specific CMake machinery that comes along
like ECM (https://github.com/KDE/extra-cmake-modules) you seems to be using.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Problem with creating shared library

2018-08-19 Thread Eric Noulard
Hi Damir,

May be the issue has nothing to do with the way you build the exported
<>Config.cmake files.
Since may be some nasty detail slipped in, could you tell us if the project
is public.
It looks like this one:
https://github.com/DamirPorobic/kImageAnnotator

may be you can push a branch that contains the exact thing that fails on
your side and it may be easier to review the detail?

on the master of this repo there does not seem to have any "example" dir.

However you already have hand written header file:
https://github.com/DamirPorobic/kImageAnnotator/blob/master/src/gui/KImageAnnotator.h

which has the very same name as the "exported header you generate":
generate_export_header(kImageAnnotator
EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
)

so may be
KImageAnnotator::KImageAnnotator(QPixmap const&)
is exposed by the hand-written file and not by the generated one so
that your unit test links ok but your "example" does not ?

Did you check the content of the generated header file?








Le dim. 19 août 2018 à 15:17, Damir Porobic  a
écrit :

> Thanks Sebastián for providing those links!
>
>
> I've followed the second link that you've provided but somehow I'm still
> running into issue.
>
>
> I've changed the directory structure to this:
>
> - kImageAnnotator
> - cmake
> - kImageAnnotator-config.cmake.in
> - example
> - main.cpp
> - CMakeLists.txt
> - include
> - kImageAnnotator
> - KImageAnnotator.h // the main api header
> - src
> - KImageAnnotator.cpp
> - "And all other .cpp and .h files"
> - CMakeLists.txt
> - CMakeLists.txt
>
> src/CMakeList.txt looks like this:
> add_library(kImageAnnotator ${kimageannotator_SRCS}
> ${CMAKE_SOURCE_DIR}/include/kImageAnnotator/KImageAnnotator.h)
>
> add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator)
>
> option(BUILD_SHARED_LIBS "Build shared library" ON)
> include(GenerateExportHeader)
>
> generate_export_header(kImageAnnotator
> EXPORT_MACRO_NAME KIMAGEANNOTATOR_API
> EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/include/KImageAnnotator.h
> )
>
> target_include_directories(kImageAnnotator
> PUBLIC
> $
> $
> $
> PRIVATE
> ${CMAKE_CURRENT_SOURCE_DIR}
> )
>
> set_target_properties(kImageAnnotator PROPERTIES
> ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
> LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib
> RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin
> )
>
> find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)
>
> find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n
> WidgetsAddons)
>
> target_link_libraries(kImageAnnotator Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> include(GNUInstallDirs)
>
> install(TARGETS kImageAnnotator
> EXPORT kImageAnnotator-targets
> ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> INCLUDES DESTINATION ${LIBLEGACY_INCLUDE_DIRS}
> )
>
> install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/kImageAnnotator
> DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> )
>
> install(EXPORT kImageAnnotator-targets
> FILE kImageAnnotator-targets.cmake
> NAMESPACE kImageAnnotator::
> DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
>
> include(CMakePackageConfigHelpers)
>
> configure_package_config_file(
> ${CMAKE_SOURCE_DIR}/cmake/kImageAnnotator-config.cmake.in
> ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
> INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
> write_basic_package_version_file(
> ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
> VERSION ${PROJECT_VERSION}
> COMPATIBILITY AnyNewerVersion
> )
>
> install(FILES
> ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config.cmake
> ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-config-version.cmake
> DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/kImageAnnotator
> )
>
> export(EXPORT kImageAnnotator-targets
> FILE ${CMAKE_BINARY_DIR}/cmake/kImageAnnotator-targets.cmake
> NAMESPACE kImageAnnotator::
> )
>
>
> kImageAnnotator-config.cmake.in looks like this:
>
> include(CMakeFindDependencyMacro)
>
> @PACKAGE_INIT@
>
> # find_dependency(Threads)
> find_package(Qt5 ${QT_MIN_VERSION} REQUIRED Widgets)
>
> find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS CoreAddons I18n
> WidgetsAddons)
>
> if(NOT TARGET kImageAnnotator::kImageAnnotator)
>   include("${CMAKE_CURRENT_LIST_DIR}/kImageAnnotator-targets.cmake")
> endif()
>
>
>
> example/CMakeLists.txt looks like this:
>
> add_executable(kImageAnnotator-example
> ${CMAKE_CURRENT_SOURCE_DIR}/main.cpp)
>
> 

[CMake] Fwd: Problem with creating shared library

2018-08-15 Thread Eric Noulard
-- Forwarded message -
From: Eric Noulard 
Date: mer. 15 août 2018 à 17:13
Subject: Re: [CMake] Problem with creating shared library
To: 


May be check the list of symbol in the lib.
KImageAnnotator::KImageAnnotator(QPixmap const&)
may really not be there (only declared in some header and not defined
anywhere).

Does the KImageAnnotator library have unit tests in its project?
If no executable linked to the ilb you won't discover the link error until
you try to link something to the lib.

This is a kind wild guess, don't take it personally :-)

Le mer. 15 août 2018 à 16:21, Damir Porobic  a
écrit :

> Thanks for the feedback.
>
>
> It looks like this line is failing:
>
> /usr/bin/c++-std=c++0x -fno-operator-names -fno-exceptions -Wall
> -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
> -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual
> -Werror=return-type  -Wl,--enable-new-dtags
> CMakeFiles/testApp.dir/main.cpp.o
> CMakeFiles/testApp.dir/testApp_automoc.cpp.o  -o testApp
> /usr/local/lib64/libkImageAnnotator.so.0.0.1
> /usr/lib64/libKF5CoreAddons.so.5.32.0 /usr/lib64/libKF5I18n.so.5.32.0
> /usr/lib64/libKF5WidgetsAddons.so.5.32.0 /usr/lib64/libQt5Widgets.so.5.6.2
> /usr/lib64/libQt5Gui.so.5.6.2 /usr/lib64/libQt5Core.so.5.6.2
> -Wl,-rpath,/usr/local/lib64
>
> The lib at /usr/local/lib64/libkImageAnnotator.so.0.0.1 seems to be
> correct, according to the sudo make install output from the lib
>
>
> Install the project...
> -- Install configuration: "Debug"
> -- Installing: /usr/local/lib64/libkImageAnnotator.so.0.0.1
> -- Installing: /usr/local/lib64/libkImageAnnotator.so.1
> -- Set runtime path of "/usr/local/lib64/libkImageAnnotator.so.0.0.1" to
> "/usr/local/lib64"
> -- Installing: /usr/local/lib64/libkImageAnnotator.so
> ...
> -- Installing:
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake
> -- Installing:
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig-debug.cmake
>
>
>
> Don't know if this is OK, but it looks like the debug and the non-debug
> cmake versions are used:
>
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(3):
> if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 2.5 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(6):
> cmake_policy(PUSH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(7):
> cmake_policy(VERSION 2.6 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(13):
> set(CMAKE_IMPORT_FILE_VERSION 1 )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(16):
> set(_targetsDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(17):
> set(_targetsNotDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(18):
> set(_expectedTargets )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(19):
> foreach(_expectedTarget kImageAnnotator )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(20):
> list(APPEND _expectedTargets ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(21):
> if(NOT TARGET ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(22):
> list(APPEND _targetsNotDefined ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(24):
> if(TARGET ${_expectedTarget} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(28):
> if(${_targetsDefined} STREQUAL ${_expectedTargets} )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(36):
> if(NOT ${_targetsDefined} STREQUAL  )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(39):
> unset(_targetsDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(40):
> unset(_targetsNotDefined )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(41):
> unset(_expectedTargets )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(45):
> get_filename_component(_IMPORT_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(46):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(47):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake(48):
> get_filename_component(_IMPORT_PREFIX ${_IMPORT_PREFIX} PATH )
> /usr/local/share/kImageAnnotatorC

Re: [CMake] Problem with creating shared library

2018-08-15 Thread Eric Noulard
Le mer. 15 août 2018 à 10:32, Damir Porobic  a
écrit :

> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
> dir1/
>
> file1.h
>
> file1.cpp
>
> dir2/
>
> file2.h
> file2.cpp
>
>
>
> Now I have this CMakeList:
>
> cmake_minimum_required(VERSION 3.5)
>
> project(kImageAnnotator VERSION 0.0.1 LANGUAGES CXX)
>
> ...
>
>
> add_library(${PROJECT_NAME} SHARED ${kimageannotator_SRCS})
> target_link_libraries(${PROJECT_NAME} Qt5::Widgets KF5::CoreAddons
> KF5::I18n KF5::WidgetsAddons)
>
> target_include_directories(${PROJECT_NAME} PUBLIC
> $ $)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES VERSION
> ${PROJECT_VERSION} SOVERSION 1)
>
> set(kimageannotator_CONFIG ${PROJECT_NAME}Config)
>
> install(TARGETS ${PROJECT_NAME} EXPORT ${kimageannotator_CONFIG}
> ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
> LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
> RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})
> install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
>
> install(EXPORT ${kimageannotator_CONFIG} DESTINATION
> share/${kimageannotator_CONFIG}/cmake)
>
> export(TARGETS ${PROJECT_NAME} FILE ${kimageannotator_CONFIG}.cmake)
>
>
> In another test project, I add the library like this:
> ...
> find_package(kImageAnnotator REQUIRED)
>
> add_executable(testApp main.cpp)
> target_link_libraries(testApp Qt5::Widgets kImageAnnotator)
>
>
> Now when I try to build my test project, I get this:
>
> dporobic@linux ~/projects/testApp/build
> $ cmake .. && make
> -- Could not set up the appstream test. appstreamcli is missing.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/dporobic/projects/testApp/build
> [ 25%] Automatic moc for target testApp
> [ 25%] Built target testApp_automoc
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o
> [ 75%] Building CXX object CMakeFiles/testApp.dir/testApp_automoc.cpp.o
> [100%] Linking CXX executable testApp
> CMakeFiles/testApp.dir/main.cpp.o: In function `main':
> main.cpp:(.text+0x8e): undefined reference to
> `KImageAnnotator::KImageAnnotator(QPixmap const&)'
> collect2: error: ld returned 1 exit status
> CMakeFiles/testApp.dir/build.make:120: recipe for target 'testApp' failed
> make[2]: *** [testApp] Error 1
> CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testApp.dir/all'
> failed
> make[1]: *** [CMakeFiles/testApp.dir/all] Error 2
> Makefile:94: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Any idea how I could/should troubleshoot such issue?
>

Try to compile in verbose mode

make VERBOSE=1

and have a look at the culprit link line.
You should see the reference to your previously built shared lib.

Check whether this lib is where it should be (may be you didn't install it?)

then check which kImageAnnotatorConfig.cmake file is used by the testApp
project in order to see if any
[wrong and not up to date] test & trial version of this file is lying
around.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

2018-08-15 Thread Eric Noulard
Le mer. 15 août 2018 à 10:57, Ray Donnelly  a
écrit :

> Docker is unnecessary overhead here and irrelevant to the question of
> which compilers to use when building conda packages (use ours or risk
> binary incompatibility with the rest of the ecosystems, please do not
> attempt to use e.g. CentOS6 system compilers to compile modern software
> either!). Docker doesn't come with modern compilers patched to support
> things like c++17 on CentOS6, they are also slow and to not mitigate
> against Spectre.
>

Hi Ray,

Don't get me wrong I certainly don't want to generate flamewar against the
benefits conda gives to many users.
I routinely use custom-compiled compilers in native environment (without
docker nor conda though) and I did never have any issue while compiling
things with CMake and those custom compilers.


> Our compilation story is very good.
>

Again I don't doubt that, and please accept my apologies if my previous
words may have been understood otherwise.


> For testing the packages though (on Linux targets) I love using docker. I
> can make sure our conda packages work on all the OSes we support.
>

Agreed too, use the right tool for the right purpose.


> You can if you want use our compilers in docker but it's pretty pointless
> (and routing conda package building thorough something like docker is a
> requirement the community, conda forge in particular does not need).
>

I don't want that I was asking question about Sebastian needs and certainly
not questioning the value of conda and in particular the conda compiler
work you did.
I know too well that having a "fully controlled compiler version" is
essential when you want to support a wide range of platforms [even various
linux distribution], precisely because you want to ensure that you can "at
least" have say C++17 on all your supported platform/distros, or common
runtime or homogeneous OpenMP support etc...


>
> I dream of a day when docker is seen as one great tool with lots of useful
> applications instead of the solution to everything but I don't see it
> coming anytime soon.
>

I really don't think docker is the solution to everything.
Again I'm sorry if my previous statement may have been understood otherwise.

Having conda/conda compiler/conda build work seamlessly working with CMake
is valuable and I'm sure you'll find the proper solution for that along
with Kitware
as already referred issue and PR indicates.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

2018-08-15 Thread Eric Noulard
Le mar. 14 août 2018 à 20:38, Sebastián Mancilla  a
écrit :

> I wanted to try Conda for normal day-to-day C++ development, while having
> all the dependencies isolated from other projects and the base system.
>
> - Change the sources
> - Build
> - Run the tests
> - Repeat
>

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology
like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better
isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like
as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda
packaged software:
https://github.com/BioContainers/mulled
I have no experience with that whatsoever, I usually craft my own
dockerfile and work with that.

If your goal includes the distrubution of your software as conda package
may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of
cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake and Visual Studio Code under linux

2018-08-09 Thread Eric Noulard
Le jeu. 9 août 2018 à 09:09, Roman Wüger  a écrit :

> Hello,
>
> how can I configure my Project to run it with the Visual Studio Code under
> Linux? I did not find a useful generator.
>

AFAIK there is no VSCode generator, however you can install VSCode CMake
Tools extension which begins to interesting to use (my opinion).
See:  https://vector-of-bool.github.io/2018/07/20/cmt-1.1.0.html

interesting meaning I think the project has matured to a point it gives you
many valuable features:
- CMake project view
- Intellisense
...
have a look at the doc as well:
https://vector-of-bool.github.io/docs/vscode-cmake-tools/index.html

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] issue with CPack: RPM package was not generated!

2018-07-31 Thread Eric Noulard
Hi Miroslav,

Do you need something very specific that you need a custom spec file?
If this is not the case you should try to let CPackRPM generate the spec
file for you.

This "USER spec file" feature was designed (quite a long time ago) when
CPackRPM was lacking some features that came in after that.
It was a debug & developer feature as well in order to ease CPackRPM
evolution.
This was made public in order to be able to "unblock" user before they get
the awaited feature in next CPackRPM release.
The USER spec file cannot be as rich as a "standard RPM spec file" there is
some restriction in what you can write in it.

In any case you can try to switch on CPackRPM debug output:
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

You should be able to get more detail about the failure.
In this mode CPack RPM will tell you where is the log/err file you can
inspect to know more.


Le mar. 31 juil. 2018 à 14:49, Miroslav Kubiczek <
miroslav.kubic...@gmail.com> a écrit :

> yes, there are install commands, one of CMakeLists.txt content:
>
> install(DIRECTORY ${PROJECT_SOURCE_DIR}/api/rest DESTINATION include)
> install(TARGETS Rest DESTINATION lib)
>
> I can see these files after running the 'make package':
> $ find ./_CPack_Packages/Linux/
> ./_CPack_Packages/Linux/
> ./_CPack_Packages/Linux/RPM
> ./_CPack_Packages/Linux/RPM/SOURCES
> ./_CPack_Packages/Linux/RPM/rpmbuildXXX-common-cpp-libs.err
> ./_CPack_Packages/Linux/RPM/tmp
> ./_CPack_Packages/Linux/RPM/rpmbuilXXX-common-cpp-libs.out
> ./_CPack_Packages/Linux/RPM/BUILDROOT
> ./_CPack_Packages/Linux/RPM/SRPMS
> ./_CPack_Packages/Linux/RPM/BUILD
> ./_CPack_Packages/Linux/RPM/SPECS
> ./_CPack_Packages/Linux/RPM/SPECS/XXX-common-cpp-libs.spec
> ./_CPack_Packages/Linux/RPM/RPMS
> ./_CPack_Packages/Linux/RPM/XXX-common-cpp-libs-7.0.0-1.x86_64.rpm
>
> I'm generating the spec file from a template by:
> configure_file("${CMAKE_CURRENT_SOURCE_DIR}/rpm/
> xxx-common-cpp-libs.spec.in"
> "${CMAKE_CURRENT_BINARY_DIR}/xxx-common-cpp-libs.spec" @ONLY IMMEDIATE)
>
> The genereated spec file looks like this:
>
> Buildroot:
> /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/xxx-common-cpp-libs-7.0.0-1.x86_64
> Summary:xxx common cpp libs
> Name:   xxx-common-cpp-libs
> Version:7.0.0
> Release:1
> License:Proprietary
> Group:  Development/Tools/Other
> Vendor: xxx
> Prefix: /usr/local
>
> %define _rpmdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
> %define _rpmfilename xxx-common-cpp-libs-7.0.0-1.x86_64.rpm
> %define _unpackaged_files_terminate_build 0
> %define _topdir /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
>
> %description
> ...
>
> # This is a shortcutted spec file generated by CMake RPM generator
> # we skip _install step because CPack does that for us.
> # We do only save CPack installed tree in _prepr
> # and then restore it in build.
> %prep
> mv $RPM_BUILD_ROOT
> /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot
>
> %install
> if [ -e $RPM_BUILD_ROOT ];
> then
>   rm -Rf $RPM_BUILD_ROOT
> fi
> mv "/data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM/tmpBBroot"
> $RPM_BUILD_ROOT
>
> %files
> %defattr(-,root,root,-)
> /usr/local/lib/*
> /usr/local/include/*
>
> 
>
> On Tue, Jul 31, 2018 at 2:30 PM, Craig Scott 
> wrote:
>
>>
>>
>> On Tue, Jul 31, 2018 at 9:56 PM, Miroslav Kubiczek <
>> miroslav.kubic...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm running cmake 3.10.1 and have this issue:
>>>
>>> $ make package
>>> [ 50%] Built target Rest
>>> [100%] Built target UT_RestLibrary
>>> Run CPack packaging tool...
>>> CPack: Create package using RPM
>>> CPack: Install projects
>>> CPack: - Run preinstall target for: XXXCommonCppLibrary
>>> CPack: - Install project: XXXCommonCppLibrary
>>> CPack: Create package
>>> CPackRPM: Will use USER specified spec file:
>>> /data/git/common-cpp-libs/build/XXX-common-cpp-libs.spec
>>> CMake Error at
>>> /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2703
>>> (message):
>>>   RPM package was not generated!
>>>   /data/git/common-cpp-libs/build/_CPack_Packages/Linux/RPM
>>> Call Stack (most recent call first):
>>>
>>> /usr/local/cmake-3.10.1-Linux-x86_64/share/cmake-3.10/Modules/CPackRPM.cmake:2774
>>> (cpack_rpm_generate_package)
>>>
>>>
>>> CPack Error: Error while execution CPackRPM.cmake
>>> CPack Error: Problem compressing the directory
>>> CPack Error: Error when generating package: XXX-common-cpp-libs
>>> make: *** [package] Error 1
>>>
>>> The rpm file is generated by those strange errors printed, make exits
>>> with an error code and jenkins build fails.
>>> Does anyone know how to fix this?
>>>
>>>
>> A few things to check:
>>
>>
>>- Have you given any install() commands in your project? The message
>>above seems to be suggesting nothing was installed.
>>- Are you overriding the .spec file rather than using the one
>>CMake/CPack creates for you? If so, can you 

Re: [CMake] Beginners Guide to Cmake and Modern Cmake

2018-07-28 Thread Eric Noulard
Le sam. 28 juil. 2018 à 01:01, spacey...@outlook.com 
a écrit :

> Hey Andreas,
>
>  thanks for your comments. Yes I too have exhausted the resources you have
> mentioned here. The concepts make sense and I see the intended point but
> for a beginner its hard to grasp on how to implement and given the type of
> project  application of cmake's is diverse (easy to complex).
>
> Im in need of some clear cut examples of modern cmake for it to really
> sink in (easy to complex).
>
> I feel you have to be a veteran in cmake to understand how to implement
> the new way and overcome the problems of dependencies not providing modern
> transitive packages and the struggle of not just calling find_package..
> etc. Instead we have to make that transition our selves in some cases. This
> is the hard part.
>


AIFAIK, your example software does not seem to be built with CMake so there
is no transition to make for you.
Just use the "Modern way" from the ground up.

Concerning documentation, tutorial, webinar etc...
More and more resource are coming up:

1) The various slide/presentation already mentionned
2) The reference documentation (https://cmake.org/documentation/) which has
improved a lot after the switch to sphinx
3) The kitware training of course: https://training.kitware.fr
4) Books
- The book recently announced by Craig Scott:
https://crascit.com/professional-cmake/
- A forthcoming cookbook:
https://www.packtpub.com/application-development/cmake-cookbook
and probably many other to come.

However if we are into making libraries it would be a benefit to know the
> process of cmake packages but at the advantage of being the maker and
> knowing the dependency path if the library does borrow.
>

I bet (but I did not read it) the book from Craig could help you with that,
but I'm sure he may answer himself.

Now I am curious of what you mean by "it would be a benefit to know **the
process of cmake packages**" ?
What do you mean by that?


> It be great to see cmake.org revamping the webinars for the
> aforementioned.
>

All that said I agree the current are oldish and would benefit an upgrade
:-)

However from my perspective writing good doc, tutorial, webinar etc... is
very time-consuming so may be worth buying some for that and give some
rewards to people investing in it.
This is my own opinion though :-)

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] ENOEXEC exit code from ctest on FreeBSD

2018-07-09 Thread Eric Noulard
Le lun. 9 juil. 2018 à 07:14, Anoop C S  a écrit :

> Hi all,
>
> While running tests from a wip branch[1] for socket_wrapper project I
> noticed the following output
> on FreeBSD:
>
>
Your issue seems more related with the "socker wrapper" project than with
CMake/CTest but...


> Following that I ran one among the failed tests from the above list using
> `ctest`:
>
> # ctest -R test_thread_echo_tcp_connect
> Test project /root/build
> Start 21: test_thread_echo_tcp_connect
> 1/1 Test #21: test_thread_echo_tcp_connect .***Failed0.07 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.07 sec
>
> The following tests FAILED:
>  21 - test_thread_echo_tcp_connect (Failed)
> Errors while running CTest
>

If you want to have more verbose output from ctest you an run:

ctest -R test_thread_echo_tcp_connect -VV

and ctest will spit out whatever output "test_thread_echo_tcp_connect" is
giving.
otherwise did you try to run the test "manually" without ctest:

from
https://git.cryptomilk.org/users/asn/socket_wrapper.git/tree/tests/CMakeLists.txt?h=master-fix
it looks like the test executable is:

test_thread_echo_tcp_connect

so try running:

./test_thread_echo_tcp_connect

and whether it fails or not.



> # uname -a
> FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
> Fri Jul 21 02:08:28 UTC
> 2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
>
You seem to be compiling and running your tests as 'root' user. This is
usually not a good idea
(even if it may not have anything to do with your failure).


> I couldn't see any genuine errors from the test logs as such. Am I missing
> something? Since I am a
> newbie to FreeBSD(and also to cmake) I would require some help to debug
> the reason for ENOEXEC exit
> code.
>

Try running in verbose mode, you may even debug into the test if you run
the test without ctest.


>
> Note:- The failed test cases uses threads.
> [1]
> https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix
>
>
Then I suggest you ask on the project mailing list what may make this test
fail.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] cpp macro

2018-06-04 Thread Eric Noulard
Le lun. 4 juin 2018 à 09:59, Stéphane Ancelot  a
écrit :

> hi
>
> is there a mactro for cpp ?
>

You mean a CMake variable which would contain the path to C preprocessor
binary?

I don't think so, at list no xxx__xxx variable seems to exists for
that.
Did you check "cmake --help-variable-list" ?

May be you can ask the compiler to act a the C pre-processor?

clang and gcc both accept the '-E' command line option to only run the
preprocessor.

otherwise you may probably call

find_program(C_PREPROCESSOR NAMES cpp)

In both cases I don't know how to discover that in a cross-platform way.
Probably MSVC has another option for pre-processsing.

Eric

>
> Regards,
>
> S.Ancelot
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [cmake-developers] How to handle dependencies of protobuf files ?

2018-05-30 Thread Eric Noulard
Le mer. 30 mai 2018 à 15:12, Brad King  a écrit :

> On 05/29/2018 04:00 PM, Alexander Neundorf wrote:
> >> In order to handle implicit dependencies like that implied by
> >>
> >> import "MyBase.proto";
> >>
> >> then they would somehow need to be extracted from source content.
> >
> > Would that have to be implemented similar to the C dependency scanning ?
>
> Yes, but even better would be if we can ask protoc to print the
> dependencies
> out for us so we don't have to parse the sources ourselves.
>

protoc can already do something like that but it spits out a makefile
includable file.

see --dependency_out=FILE option.
Write a dependency output file in the format
  expected by make. This writes the transitive
  set of input file paths to FILE

moreover the generated makefile depends on the langage generator used
(--cpp_out, --java_out, --python_out, ...) because dependencies are
expressed between proto and
generated source files.

May be it would be possible to write a protoc "plugin"
https://www.expobrain.net/2015/09/13/create-a-plugin-for-google-protocol-buffer/

which would spit out easy to digest dep spec for CMake.

Unfortunately I'm not volunteering :-( just giving some idea.


> > so the cheap solution would be to add an argument to
> PROTOBUF_GENERATE_CPP()
> > to list proto-files these proto-files depend on
>
> Yes, that would be a good intermediate solution.
>
> -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:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] [CPack] Avoiding packaging (some) dependencies

2018-05-16 Thread Eric Noulard
2018-05-16 9:33 GMT+02:00 Drago Trusk :

> Hi everyone,
>
> I have particular problem which I'm unable to solve.
>
> Lets say there are following components:
>  - Main: library/executable
>  - Ignorable: Main requires it to build, but not for packaging
>
> Main simply defines:
> add_dependencies(Main Ignorable)
>
> FindIgnorable.cmake contains something like:
> add_custom_target(Ignorable
>   COMMAND ... ... && cmake --build --target install .
>   # ...
> )
>
> Problem is that deb cpack generator picks this from install tree (tar/zip
> doesn't contain Ignorable). So deb ends up with:
> # ... correct fs hierarchy
> /home/saduser/projects/ignorableinstall
>
> I need to avoid dependency used only for building artifacts.
>
> What I found:
> - Remove add_dependency
>  Problem: have to build dependencies manually and will break CI and
> other people builds
> - Disable automatic packaging of everything and specify custom components
> to package
>  Problem: Dependency tree which might be bigger and requires to know
> too many details. In addition requires for outside  changes so that all
> targets have (appropriate)  install conponents.
>
> I tried everything else that is possible. Am i missing something or are
> those two only viable options?
>

I think the second option should be ok and not that complicated.
Put the "Ignorable" in an "IgnoredComp" install component and remove this
component from the list of installed components.

get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
list(REMOVE_ITEM CPACK_COMPONENTS_ALL """)

see: https://cmake.org/cmake/help/v3.11/module/CPackComponent.html

AFAIR you don't need to defined a component for every install because CPack
already does that for you.
I think that every bits installed without component specification ends-up
in the trap-them-all
"Unspecified" component which is automatically created by CPack.

see:
https://cmake.org/cmake/help/v3.11/variable/CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.html

Another way to do that even more simply (**if you are sure no component are
defined**)
would be to:

1) install ignorable in "IgnoredComp" component
2) let all other be in your default component
set(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "InstallThatOnly")
3) only install your default component
set(CPACK_COMPONENTS_ALL "InstallThatOnly")


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Recommandations for public custom macro/functions installation

2018-04-17 Thread Eric Noulard
2018-04-17 11:58 GMT+02:00 David Demelier :

> Hello,
>
> In my application I have some custom functions that help the process of
> creating executable, libraries, plugins and such.
>
> They don't do magic things but they mostly build, provide installation
> to specific place and optionally build the documentation and install
> them as well. This happens in my project. Since the project is
> extensible, I want to install the libraries **and** those macros so
> users will be able to use them so their plugins get installed in the
> correct place alongside the documentation without much effort.
>
> Example, the user will just write:
>
> irccd_define_plugin(
> SOURCES main.cpp
> DOCS myplugin.md
> )
>
> The problem with that macro, is that it has a conditional to build the
> documentation depending on an option. This is fine in my project since
> the user may build or not build the documentation by setting WITH_DOCS
> to Off.


> Now I wonder how I should handle this option when the macro is
> publicliy installed. The most problematic question is that variables do
> not have namespaces so if the user of my macro also have an option
> WITH_DOCS in its own CMakeLists.txt, this will interfer with the
> installed macro.
>

Add an optional BUILD_DOCS option parameter to your macro  with default to
"False" if not present
so that user cannot call it without knowing.

i.e.

You will call:

irccd_define_plugin(
SOURCES main.cpp
DOCS myplugin.md
BUILD_DOCS ${WITH_DOC}
)

your user may safely call:

irccd_define_plugin(
SOURCES main.cpp
DOCS userplugin.md
)


Another option would be to carry "doc generation option" as a target level
custom property
you can attach to each target (exe, plugins , etc...) created by your macro.

Then your macro may decide to generate doc iff the chosen property is
defined on a per-target basis.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

2018-03-23 Thread Eric Noulard
2018-03-23 11:44 GMT+01:00 Mario Emmenlauer <ma...@emmenlauer.de>:

>
> Hi Eric,
>
> On 23.03.2018 10:58, Eric Noulard wrote:
> > 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer <ma...@emmenlauer.de
> <mailto:ma...@emmenlauer.de>>:
> >
> >
> > Thanks PF, I think this makes more sense now! I was assuming that
> > cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
> > clarified, that only applies to libraries that provide find_package
> > support.
> >
> > This is actually quite unfortunate. Then I don't see an easy way to
> > enforce usage of specific libs. As an example, if I want to enforce a
> > patched libtiff (that does not itself provide find_package support)
> > the only "safe" way is to replace the system libtiff. Otherwise any
> > package might just find the system version first without me even
> > knowing.
> >
> >
> > You can always ship your own/patched version of  Find.cmake
> module with your
> > project source and build the 'local' override logic in it for every
> project/lib that does not provide a find_package.
> >
> > Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)
> >
> > something like:
> >  list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)
> >
> > before using find_package etc...
> >
> > I find it a "safer" solution than system lib replacement.
> > My opinion though.
>
> I was considering this option too. But in my original email I outlined
> that this is not only for my own package, but additionally for more than
> 30 thirdparty dependencies. So its not only about ensuring that my
> packages use the correct thirdparty version, furthermore the packages
> themselves have inter-dependencies that must be correctly resolved.
>

Sorry I missed that part on third party.



> So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG,
> FindPROJ4,
> FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty
> dependencies. It would create a maintenance hell :-(
>

Yep I can perfectly imagine.
I know well a project for which we do exactly that.

1) Collect all third party sources for which we want to control precise
version (and/or need a patch)
2) Configure, compile and install them all on a private dir
3) Configure and  build my project using those installed 3rd party libs.

this is the only way we can find to have "clean" multi-linux-distrib'
support.


How are other people resolving this?
>

I'm interesting in this as well, but as soon as a 3rd party is using
something you use
you end-up putting your hand in third party or override system lib (which
is not an option for us).

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] should zlib be searched in CMAKE_PREFIX_PATH or am I confused?

2018-03-23 Thread Eric Noulard
2018-03-23 10:21 GMT+01:00 Mario Emmenlauer :

>
> Thanks PF, I think this makes more sense now! I was assuming that
> cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you
> clarified, that only applies to libraries that provide find_package
> support.
>
> This is actually quite unfortunate. Then I don't see an easy way to
> enforce usage of specific libs. As an example, if I want to enforce a
> patched libtiff (that does not itself provide find_package support)
> the only "safe" way is to replace the system libtiff. Otherwise any
> package might just find the system version first without me even
> knowing.
>

You can always ship your own/patched version of  Find.cmake
module with your
project source and build the 'local' override logic in it for every
project/lib that does not provide a find_package.

Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)

something like:
 list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)

before using find_package etc...

I find it a "safer" solution than system lib replacement.
My opinion though.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Make ctest spit out xml file (without dashboard)

2018-03-19 Thread Eric Noulard
2018-03-19 13:14 GMT+01:00 Craig Scott <craig.sc...@crascit.com>:

>
>
> On Mon, Mar 19, 2018 at 10:39 PM, Eric Noulard <eric.noul...@gmail.com>
> wrote:
>
>> Hi there,
>>
>> Is it possible to make ctest spit out its result in an xml formatted file
>> without
>> sending it to some dashboard. ?
>>
>
> Yes, you can control the individual steps of a full dashboard run and just
> leave out the submit step. For example:
>
> ctest -T Start -T Update -T Configure -T Build -T Test -T Coverage -T
> MemCheck
>
> Leave out any of the above -T actions you don't need. XML result files
> will be in a Testing/MMDD-hhmm directory and log files in
> Testing/Temporary. The Start action creates a new MMDD-hhmm timestamp
> directory that the rest of the steps will then store their XML result files
> in. The first line of the file at Testing/TAG records that timestamp and
> the second line in there you won't care about if not submitting the results
> to a dashboard.
>
> Hopefully that gets you far enough along to what you need.
>

This is indeed far just enough for my needs.
Thank you very much Craig.


-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] Make ctest spit out xml file (without dashboard)

2018-03-19 Thread Eric Noulard
Hi there,

Is it possible to make ctest spit out its result in an xml formatted file
without
sending it to some dashboard. ?

I only need something xml-parsable ctest output locally.

-- 
Eric
-- 

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:
https://cmake.org/mailman/listinfo/cmake


  1   2   3   4   5   6   7   8   9   10   >