from:"Florent Castelli"

Re: [cmake-developers] Compile targets affected by changeset

2017-05-22 Thread Florent Castelli

Depending on your setup and the amount of build machines, you may have 
even better results with sccache from Mozilla. It's a new implementation 
similar to ccache with an optional distributed cache in S3 or Redis.


The downside is if you have long running tests in the list, it won't 
help you much (unless you have a way to checksum the test programs and 
skip them maybe?). But still, it's always a good thing to rerun them as 
you may have some unstable tests and more runs means more confidence.


/Florent

On 22/05/2017 23:06, Craig Scott wrote:
I highly recommend Florent's suggestion. We use ccache on our CI 
system and for local development. We've stopped worrying about how 
long builds take now, since only files that are changed or that rely 
on things that changed contribute any meaningful amount to the build 
time. It also works for Make, Ninja and Xcode, so it's more flexible 
than relying on some feature of Make and it is also pretty easy to set 
up. You can set it up system wide, or you can take the approach 
discussed in this article 
<https://crascit.com/2016/04/09/using-ccache-with-cmake/> for systems 
where you don't have access to set up ccache globally.



On Tue, May 23, 2017 at 4:54 AM, Florent Castelli 
<florent.caste...@gmail.com <mailto:florent.caste...@gmail.com>> wrote:




On 22 May 2017, at 20:07, Robert Patterson via cmake-developers
<cmake-developers@cmake.org <mailto:cmake-developers@cmake.org>>
wrote:

We understand that CMake and make already can rebuild targets
which depend on changed files, and this behavior works exactly as
expected for us. Our issue is not that make is rebuilding targets
that it shouldn't. We would like this 'compile targets which
changed' behavior to work from a clean state, not just for
subsequent rebuilds. That is, from the first time cmake / make is
invoked, only the targets that depend on the given set of files
will be built, and no more.

When a developer submits a changeset to our continuous
integration tool, a fresh copy of the repository is checked out
by the worker at the commit of the changeset. We can access the
set of changed files from the commit data. Currently, cmake and
make correctly identify that the system is in a clean state and
that everything should be built if the current top-level target
is specified. This is the point where we would like our behavior
to differ. We want the rebuild changed targets behavior as if
everything were already built, but from this clean state.

Once we have determined the targets to build, we could simply
specify these targets as goals to make in the command line, but
we are hampered by the following limitation of make.

We are using GNU make 3.82. Invoking 'make -j target1 target2
target3' on the command line specifies the targets as goals to
make. If several goals are specified, 'make' processes each of
them in turn, in the order you name them.
https://www.gnu.org/software/make/manual/html_node/Goals.html
<https://www.gnu.org/software/make/manual/html_node/Goals.html>

Ninja does not currently work for our project.


It would be interesting to fix Ninja for your project then. Do you
know what isn’t currently working?
Also, Ninja has some APIs to expose all the dependency graph,
which you could probably query somehow to find out which target
you need to rebuild.

Another possibility, albeit a bit different, could be to use a
compilation cache to just rebuild everything but much faster, to
the point that it might not be relevant anymore.

/Florent




On May 19, 2017, at 2:32 AM, Simon Richter
<simon.rich...@hogyros.de <mailto:simon.rich...@hogyros.de>> wrote:

Hi,

On 18.05.2017 23:48, Robert Patterson via cmake-developers wrote:


My company has a large, predominately C++ codebase, with
hundreds of
targets, both for product and unit tests.  In an effort to
improve the
compile and test time for developers, which utilizes a continuous
integration infrastructure, it is desirable to compile only the
targets
that are affected by developer's change sets.


Erm, it should already work this way. If Make rebuilds a target
that it
shouldn't, the first step would be investigating why it thinks the
target needs to be rebuilt.

Dependency tracking is one of the oldest problems, and cmake
should use
an appropriate solution for the actual build system you use. The
approach used for Make is a bit more conservative than you would
require
for GNU Make, but should nevertheless still work.

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
<http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/>

is a good primer on dependency list generation with Make -- CMake
gener

Re: [cmake-developers] Compile targets affected by changeset

2017-05-22 Thread Florent Castelli


> On 22 May 2017, at 20:07, Robert Patterson via cmake-developers 
>  wrote:
> 
> We understand that CMake and make already can rebuild targets which depend on 
> changed files, and this behavior works exactly as expected for us. Our issue 
> is not that make is rebuilding targets that it shouldn't. We would like this 
> 'compile targets which changed' behavior to work from a clean state, not just 
> for subsequent rebuilds. That is, from the first time cmake / make is 
> invoked, only the targets that depend on the given set of files will be 
> built, and no more.
> 
> When a developer submits a changeset to our continuous integration tool, a 
> fresh copy of the repository is checked out by the worker at the commit of 
> the changeset. We can access the set of changed files from the commit data. 
> Currently, cmake and make correctly identify that the system is in a clean 
> state and that everything should be built if the current top-level target is 
> specified. This is the point where we would like our behavior to differ. We 
> want the rebuild changed targets behavior as if everything were already 
> built, but from this clean state.
> 
> Once we have determined the targets to build, we could simply specify these 
> targets as goals to make in the command line, but we are hampered by the 
> following limitation of make.
> 
> We are using GNU make 3.82. Invoking 'make -j target1 target2 target3' on the 
> command line specifies the targets as goals to make. If several goals are 
> specified, 'make' processes each of them in turn, in the order you name them. 
> https://www.gnu.org/software/make/manual/html_node/Goals.html 
> 
> 
> Ninja does not currently work for our project.

It would be interesting to fix Ninja for your project then. Do you know what 
isn’t currently working?
Also, Ninja has some APIs to expose all the dependency graph, which you could 
probably query somehow to find out which target you need to rebuild.

Another possibility, albeit a bit different, could be to use a compilation 
cache to just rebuild everything but much faster, to the point that it might 
not be relevant anymore.

/Florent

> 
>> On May 19, 2017, at 2:32 AM, Simon Richter > > wrote:
>> 
>> Hi,
>> 
>> On 18.05.2017 23:48, Robert Patterson via cmake-developers wrote:
>> 
>>> My company has a large, predominately C++ codebase, with hundreds of
>>> targets, both for product and unit tests.  In an effort to improve the
>>> compile and test time for developers, which utilizes a continuous
>>> integration infrastructure, it is desirable to compile only the targets
>>> that are affected by developer's change sets.
>> 
>> Erm, it should already work this way. If Make rebuilds a target that it
>> shouldn't, the first step would be investigating why it thinks the
>> target needs to be rebuilt.
>> 
>> Dependency tracking is one of the oldest problems, and cmake should use
>> an appropriate solution for the actual build system you use. The
>> approach used for Make is a bit more conservative than you would require
>> for GNU Make, but should nevertheless still work.
>> 
>> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ 
>> 
>> 
>> is a good primer on dependency list generation with Make -- CMake
>> generates rules that are similar to these.
>> 
>>> 'make' has a limitation where if 'make target1 target2 target3' is
>>> invoked, target1, target2, and target3 are built serially, not in
>>> parallel.
>> 
>> Which version of make are you using?
>> 
>>   Simon
>> 
>> -- 
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
> 
> -- 
> 
> 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 
>

Re: [cmake-developers] Support for unified headers in Android NDK

2017-04-20 Thread Florent Castelli

I just came back from some holidays now, I'll try to update the MR with the
latest changes soon next week!

/Florent

On Apr 20, 2017 10:10 PM, "Robert Dailey"  wrote:

> I may pick this up, because right now it's impossible to use libc++
> (LLVM) with an API less than 21 since that's when clang was
> introduced. libc is missing too many symbols that are required by
> libc++ below API 21.
>
> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel 
> wrote:
> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> >> Google is supporting unified headers for sysroot as of NDK r14:
> >>
> >> https://android.googlesource.com/platform/ndk/+/master/
> docs/UnifiedHeaders.md
> >>
> >> Is there a plan to add support for this natively into CMake?
> >
> > There is a merge request that is in-progress, but was closed due to
> > inactivity (lack of time on Florent's side it seems). I'd recommend
> > coordinating with Florent to resurrect the MR.
> >
> > https://gitlab.kitware.com/cmake/cmake/merge_requests/492
> >
> > --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:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

2017-01-16 Thread Florent Castelli


> 
> It's up to users to use generator expressions instead of if(WIN32) or 
> whatever:
> 
> add_library(foo
>   foo.cpp
>   $<$:foo_win.cpp>
> )
> 
> This has been possible for years and was designed with IDEs in mind:

Sure, it’s possible, but it’s not very user friendly or declarative (you need 
to parse and interpret the generator expression).

> 
> http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html
> 
>> I find that most of the conditionals are just to create the list of
>> sources per platform and then the list of dependencies. It’s certainly
>> possible to use generator expressions for some cases, but they don’t have
>> the prettiest syntax around, and maybe also not access to all the local
>> variables that you need to pick the right files.
> 
> You should be able to put any configure-time variable through the generator 
> expressions $ or $ to make them genex-compatible.

Same, it’s not user friendly or a great syntax.
I’ve rarely seen any advanced usage in projects in the wild, I think for that 
very reason.

One thing that I dislike in genex is that there is no “else” clause.
So you have to duplicate the whole condition and add a $ around it.
Having something close to a ternary operator would be nice.

/Florent
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

2017-01-16 Thread Florent Castelli

Well, CMake scripts can be written in a somewhat declarative form now.
What prevents this now is that a lot of people use indirections everywhere. For 
example: add_library(foo STATIC ${SRCS})
If it was a plain list, any decent IDE would be able to parse this and add 
another file to the list easily.
If some commands allowed more expressive alternative forms, it would definitely 
improve the situation:

add_library(foo STATIC
  bar1.c
  bar2.c
  WINDOWS
  windows-specific.c
  APPLE
  apple-specific.m
)

I find that most of the conditionals are just to create the list of sources per 
platform and then the list of dependencies. It’s certainly possible to use 
generator expressions for some cases, but they don’t have the prettiest syntax 
around, and maybe also not access to all the local variables that you need to 
pick the right files.

In my company, I got annoyed by all the people who just copy pasted CMake files 
(in imperative form) around without understanding what was everything doing, so 
I made some functions with parameters similar to the example above and 
everything became a (custom) declarative format. 
It had the benefit of fixing all the copy issues around (that was just annoying 
boilerplate) and introduce some interesting sanity checks:
 - checking that all the files in the source folder are used (so we don’t miss 
a header for IDE users for example or leave stray files around)
 - checking that all the include folders exist (this prevents some spelling 
mistakes)
 - checking that all the include folders are relative and don’t go back in the 
hierarchy or aren’t absolute (for a cleaner project structure and preventing 
undeclared dependencies between targets)
 - checking for dependency cycles (and erroring on them), CMake tolerates this, 
not my coding standards (btw, it’s fun to write graph DFS algorithms in the 
CMake language)
 - translating “Framework::Foobar” to the right calls to find the frameworks 
and link against it without more boilerplate
 - translating “FOO::FOO” to a find_package() call and using the imported 
target automatically in some circumstances
All of that was done because CMake has a powerful scripting language, so it’s 
definitely interesting to have one!

Maybe CMake doesn’t need a real declarative mode, it just needs a small set of 
user friendly functions that does the same thing as the low level ones and can 
be easily edited by IDEs?

/Florent

> On 16 Jan 2017, at 21:02, Shmuel H,  wrote:
> 
> > My point is that an IDE should be able to edit the declarative spec
> > without having run a configuration or even create a build tree.  The
> > spec should be the preferred form for making changes and stored in
> > version control.  Any intermediate spec generated by a procedural
> > Language script cannot serve this role.
> 
> I understand that. Maybe we should let the user decide whether to use the 
> advantages the declarative spec or to use a script to generate it. That way, 
> we would not lose the scripting future, which is a big future of CMake. On 
> the other side, we would not force users to use that and even we would make 
> it a lot easier for IDEs to manage these projects.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Unknown Imported & Global libraries

2017-01-09 Thread Florent Castelli

> On 9 Jan 2017, at 20:55, Brad King <brad.k...@kitware.com> wrote:
> 
> On 12/21/2016 07:12 AM, Florent Castelli wrote:
>> find_package(foo)
>> if(NOT FOO_FOUND)
>>  add_library(foo STATIC foo.cpp)
>> endif()
> 
> Instead do
> 
>  find_package(foo)
>  if(NOT FOO_FOUND)
>add_subdirectory(bundled_foo)
>  endif()
> 
> so that the imported targets are visible.  Inside the bundled_foo you can 
> build
> the target and then crate an ALIAS library whose name matches what the 
> imported
> target would have been.
> 

The problem with that approach is that it’s up to the “caller” to put that 
boilerplate and it would be much nicer to have all of that in the callee, all 
within the same script.
Additionally, all the bundled library are usually setup in another folder 
“ext”, “vendor”, “3rdparty” which will be a different context and won’t make 
those available to the rest of the code.

>> make imported libraries global by default
> 
> The reason they are locally scoped is that find_package() may load
> different, possibly conflicting, external packages in separate directories.
> The find_package() call should be made at the highest level that contains
> anything that directly references the target.  See above example.
> 

If the libraries don’t come from a find_package() call but my code, it should 
be my responsibility to make sure there’s no 2 conflicting libraries with the 
same name.
If I can guarantee that, then that is an annoying restriction on imported 
targets. 

> An alternative is:
> 
>  find_package(foo)
>  add_library(Foo INTERFACE)
>  target_link_libraries(Foo PUBLIC FOO::FOO)
> 
> That will make a globally visible Foo target that when used forwards all
> usage requirements from the imported target.
> 

That’s another approach I’m considering. It’s just annoying that “FOO::FOO” 
becomes reserved as I’d rather have the external libraries “namespaced”, and I 
can’t redefine an alias.
I guess I could set their name to Ext::FOO::FOO instead which would be decent.
Again, that’s some more annoying boilerplate.

Note it should also be INTERFACE and not PUBLIC in there.

> -Brad
> 

Anyway, this still doesn’t explain why “UNKNOWN IMPORTED” and “GLOBAL” keywords 
don’t work with each other. My guess is they should under a controlled setup, 
but I couldn’t make it work.

/Florent
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Unknown Imported & Global libraries

2016-12-21 Thread Florent Castelli

Hi,

In my project, I have to deal with 3rd party libraries. Either the library is 
available on the system and then I will try to use that, or I will use sources 
bundled in my repository. This is in order to make Linux maintainers happy who 
want to have a system-wide shared library, but to also keep a self contained 
build available by default.
But all that logic is cumbersome, so it usually ends up in a dedicated file 
looking like:

find_package(foo)
if(NOT FOO_FOUND)
  add_library(foo STATIC foo.cpp)
endif()

Then with modern CMake, you don’t just get variables but imported targets, 
usually defined with something like:
add_library(FOO::FOO UNKNOWN IMPORTED)

All those scripts being used through multiple levels of add_subdirectory() 
calls, makes it so that the imported targets are only scoped to the leaf file 
and not visible to the other libraries that may want to use it.
One way to work around that would be to mark them GLOBAL. But the problem is 
that I then get an error such as:
CMake Error at CMakeLists.txt:1533 (target_link_libraries):
  Target “FOO::FOO" of type UNKNOWN_LIBRARY may not be linked into
  another target.  One may link only to STATIC or SHARED libraries, or to
  executables with the ENABLE_EXPORTS property set.
Without the GLOBAL keyword, it links just fine (as long as I keep the 
definition in the same scope). So why would GLOBAL trigger a different 
behaviour?

Any ideas why that would be? I went through the code quickly, but I didn’t find 
anything relevant, so I’m quite puzzled.

I know I could use instead include() instead of add_subdirectory() to go 
through the external dependencies but I believe that’s a wrong fix. Scoping 
variables is actually nice.

Also, I would very much desire a setting to make imported libraries global by 
default to increase the legibility of most code and avoid having huge CMake 
scripts as most people currently do. Splitting targets in different files 
should be the norm!
I can also override add_library to add the GLOBAL keyword automatically, which 
would work if UNKNOWN IMPORTED GLOBAL was actually working...

/Florent
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Android variables

2016-11-12 Thread Florent Castelli

On 12/11/2016 13:35, Ruslan Baratov wrote:

On 12-Nov-16 19:09, Florent Castelli wrote:

On 12/11/2016 06:53, Ruslan Baratov wrote:

On 12-Nov-16 08:21, Florent Castelli wrote:

On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:

Hi,

I wonder if it's possible to introduce next variables describing
Android

tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that
will

contain the path to preprocessor. Example:
* CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++

* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp

* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
* CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++

Of course if I'm not missing something and they are not already
somewhere :)

Ruslo

How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?

I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.
Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
locally and it will work with GCC-like compilers.
That's a more robust way to call it as there is no
CMAKE_C_PREPROCESSOR standard value in any CMake file.
Nobody should call "cpp" manually anymore, but use the compiler
driver instead to do it for you.

That's why there's no standard CPP variable in CMake, it's not needed
at all.
For the same reasons, you rarely have to call the linker directly,
it's usually done through the compiler driver.
Just like I said I'm not using it - this variable needed for 3rd party
package. I have no idea how it was used, the only thing I know is that
if I remove this variable the package stop working.
Then just set it yourself as I said. You don't even need 3.7.0, you can
just override it in the current version of CMake and previous toolchain
you used. The 3rd party package using it should still work.

Use small incremental steps, in order to migrate. It will be easier.

Calling it directly is kind of dangerous though since you will
probably be missing the proper language information and other options
that might affect the predefined preprocessor defines.
I'm not calling it directly, it was used by `configure` script of
3rd party.

gcc has different binaries for different target archs and has some
defines baked in, but this won't apply to Clang that uses only one
binary and a target triple.
For clang based android toolchain the
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX

variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)

I think that's an implementation detail you shouldn't rely on. The
compilers in the NDK are changing, GCC is deprecated and you
shouldn't expect that.
Clang is mostly self contained and using very little from the GCC
distribution (binutils), it will be gone at some point, so you should
be ready for the future.
My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
bother about the destiny of GCC distribution. When this stuff will
change the problems will appear in both taka-no-me and CMake 3.7+.
Well, you should care as the cpp program will likely disappear and you
will need other means to preprocess anything directly (gcc/clang -E).
Better do it now and break one of the last dependency you have and
migrate away from old custom variables.

If you're updating CMake and changing the toolchain file, then I
would expect that some work has to be done, including making changes
to the invocation of a 3rd party script that is using custom
variables from the old toolchain.
There is a tricky part about that. I do define variables like
CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after**
toolchain processed hence I can't use such variable in toolchain to
create my custom variables. So if we want to have everything play nice
this should be defined in CMake.
Why do you need that variable to be defined in the toolchain? It
shouldn't be a problem to define it outside of it or just before you use
the 3rd party package that is using it.

Overall, I consider that taka-no-me Android toolchain to be tech
debt. It hasn't been updated for a long time, doesn't work with
recent NDK (unless you resort to use a standalone toolchain), locks
people with some custom variables making them believe they are
standard and has tons of other small bugs and issues.
I understand its appeal for most people, but to me, it has caused
more trouble than help.
Just like I said before, those variables neede

Re: [cmake-developers] Android variables

2016-11-12 Thread Florent Castelli

On 12/11/2016 06:53, Ruslan Baratov wrote:

On 12-Nov-16 08:21, Florent Castelli wrote:

On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:

Hi,

* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp

Of course if I'm not missing something and they are not already
somewhere :)

Ruslo

How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?

I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.
Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
locally and it will work with GCC-like compilers.
That's a more robust way to call it as there is no CMAKE_C_PREPROCESSOR
standard value in any CMake file.
Nobody should call "cpp" manually anymore, but use the compiler driver
instead to do it for you.

That's why there's no standard CPP variable in CMake, it's not needed at
all.
For the same reasons, you rarely have to call the linker directly, it's
usually done through the compiler driver.

Calling it directly is kind of dangerous though since you will
probably be missing the proper language information and other options
that might affect the predefined preprocessor defines.

I'm not calling it directly, it was used by `configure` script of 3rd party.

gcc has different binaries for different target archs and has some
defines baked in, but this won't apply to Clang that uses only one
binary and a target triple.

For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)

Overall, I consider that taka-no-me Android toolchain to be tech debt.
It hasn't been updated for a long time, doesn't work with recent NDK
(unless you resort to use a standalone toolchain), locks people with
some custom variables making them believe they are standard and has tons
of other small bugs and issues.
I understand its appeal for most people, but to me, it has caused more
trouble than help. It could have been done so much better.

/Florent
--

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Android variables

2016-11-11 Thread Florent Castelli

On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:

Hi,

I wonder if it's possible to introduce next variables describing Android
tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
contain the path to preprocessor. Example:
* CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
* CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++

Of course if I'm not missing something and they are not already somewhere :)

Ruslo

How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? Calling
it directly is kind of dangerous though since you will probably be
missing the proper language information and other options that might
affect the predefined preprocessor defines. gcc has different binaries
for different target archs and has some defines baked in, but this won't
apply to Clang that uses only one binary and a target triple. You'll
also lose the c/c++ language definition (unless you pass -x c++),
language standard in use...

gcc (or clang) are just "drivers". They will call the proper programs
automatically. Either the preprocessor, the compiler (cc1) or the
linker, so you should be able to do everything with it directly!

As for the ANDROID_TOOLCHAIN_MACHINE_NAME that is used for gcc prefix,
it shouldn't be needed. If you rely on gcc, you should investigate on
using Clang which is the supported compiler now in the NDK. What is your
exact usage of the variable?

/Florent

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Add property to get all linked libraries including transitive ones

2016-11-02 Thread Florent Castelli

One usage I would have had for this feature would have been to generate 
a pre-linked library.
Basically, merging a static library and its dependencies together (check 
ld -r) and output an object file for static linking (not a shared library).
This is required as merging static libraries may conflict on filenames 
in the archive (they could be renamed though) or generate huge archives 
(hey, here's 1000 copies of std::string and std::vector methods and 
their debug symbols).


Instead, I recursed on all the dependencies to generate an extra build 
step to merge everything. The file is small and can be cached.
We did that to save time for our iOS devs so they didn't have to rebuild 
our big C++ library all the time. We targeted iOS 7, so shared libraries 
were not available.


It's a bit more involved, but it would have been useful. Though, I 
understand it can be tricky to get the on-disk path to a library with 
all generators (we had 2 code paths, one for Xcode builds and another 
one for Ninja).


/Florent

On 02/11/2016 12:56, Brad King wrote:

On 11/01/2016 04:30 PM, maikel van den Hurk wrote:

obtain actually all transitive linked libraries of a specific target.

[snip]

this information is only fully available during generation time.

What is an example use case for this?  I don't think we can offer a
configure-time solution but perhaps there is a generate-time solution
to the use case.

-Brad



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake integration in Gradle (Android Studio)

2016-10-31 Thread Florent Castelli


I tried the Gradle + CMake integration and I'm not really impressed.
I would recommend not using it right now until they fix the rough edges.

The prime concern is that it is REALLY hard to get the CMake output and 
compilation output,
even within Android Studio. If you compile from command line, you won't 
see much.
This is a no go for CI environments where you need to see what went 
wrong and also some
output once in a while (or builds are usually considered stuck and 
canceled if they take too long).

See the issue: https://code.google.com/p/android/issues/detail?id=210930

Installing CMake within the SDK is not trivial. There's an open bug with 
a proposed solution,
it's not pretty stuff but does the work: 
https://code.google.com/p/android/issues/detail?id=221907
An alternative would be to repackage your SDK folder after running 
Android Studio and installing
everything you need and distribute that to your CI build machines / 
developer machines.


But essentially, what you want is probably just use their toolchain 
file, which is much better
than the OpenCV one. You can find it bundled in the latest NDK and I 
guess you could be using
that directly with CMake. If it is doing weird things, I guess you could 
have a look at it and debug it.
It's not as complicated as the OpenCV one and I hope you'll find the 
solution to your issues!


As for CMake 3.7, when I asked about it in this mailing list, someone 
said there will be
a compatibility layer to the toolchain to reuse the upstream support 
when it's available

if I remember correctly.

/Florent

On 25/10/2016 15:48, Robert Dailey wrote:

I'm not sure if the CMake mailing lists are the right place to ask
this question but I thought I'd ask just in case someone has gone down
this path or has experience with what Google/Gradle is actually trying
to accomplish with what seems to be a hand-built version of CMake with
custom patches that are not in upstream repositories.

Prior to switching to Android Studio / Gradle, I was using Eclipse /
Ant. The way I did CMake integration was not really integration at
all: I generated Ninja build scripts using CMake and implemented
custom targets to run "ant release" after all the C++ projects were
built. I made sure that CMake copied relevant *.so files to
appropriate directories in the Ant structure so they are packaged with
built APKs. That's how I did my Android development.

Now that I'm integrating CMake into Gradle, first annoyance I noticed
is that I can't use CMake 3.7 (or any external installation of CMake)
with Android Studio. It requires a version of CMake installed through
SDK Manager. This means I can't use the new Android toolchain
functionality built into CMake 3.7 (sad face). But this is something I
can work around...

Next I found out that stuff I'm setting in my CMake scripts, such as
CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
For whatever reason, Gradle is overriding these from the command line
(I'm guessing?). So this requires me to duplicate the toolchain /
compiler flag setup I already do in my CMake scripts now in the Gradle
build scripts. This seems completely unnecessary and a maintenance
burden.

What I was expecting Gradle to do was essentially provide me some
toolchain file so that CMake can find the compiler and linker to use
and then the rest would be determined by CMake itself.

Is there a way I can tell Gradle to not take so much control over
compiler flags? I want my CMake scripts to do this. I can't imagine
they had a good reason to do this. What have others done in this
situation with their own Gradle + CMake integration? Looking for
advice here, since information is sparse, especially since the Android
Studio 2.2 CMake integration is relatively new stuff.



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Android Support

2016-09-27 Thread Florent Castelli

That’s great to know, thanks!
Is there any plan on having their toolchain in CMake directly at some point?

I’m afraid that even if they update their options to use the upstream support, 
they may not allow using those options directly and we’ll still have to support 
2 toolchains.
That’s especially true if you chose not to build with Gradle but a standalone 
CMake build (using upstream) and then don’t have access to their toolchain file.

/Orphis

> On 27 Sep 2016, at 13:51, Brad King  wrote:
> 
> On 09/26/2016 05:50 PM, David Neto wrote:
>>> I just don't want to have 2 toolchains to support, that would be really 
>>> terrible :(
>> 
>> I work for Google but not in this area, and I don't know who is doing this 
>> support.
>> I suspect this is just an accidental duplication of effort.
> 
> I have been in contact with them.  They are aware of what CMake 3.7 will have
> and plan to port their toolchain files to take advantage of it.  They can 
> simply
> map their options to CMake's new equivalents.
> 
> The two efforts were mostly orthogonal.  CMake's side of the work makes
> toolchain files much simpler, but does not actually provide any toolchain 
> files.
> The NDK's side of the work provides toolchain files that are aware of exactly
> what comes with the NDK.
> 
> -Brad
> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Android Support

2016-09-26 Thread Florent Castelli


On 12/09/2016 15:09, Brad King wrote:

On 09/09/2016 04:04 PM, Robert Dailey wrote:

Currently nightly builds are tagged 3.6.2. Are there no nightly builds
for 3.7 or am I missing something?

They are 3.6.2.$date, indicating post-3.6 feature development.
See the documentation of CMAKE_VERSION:

  https://cmake.org/cmake/help/v3.6/variable/CMAKE_VERSION.html

-Brad


Resurrecting this!

I've seen that the Android Gradle build tools now have an official CMake 
plugin that has a custom 3.6 version with a custom toolchain and Android 
platform support.

https://developer.android.com/ndk/guides/cmake.html#variables

The problem is that they have a set of configuration options for their 
toolchain that is similar to what you have, but incompatible.


Have you tried working it out with Google? Maybe dropping your 
implementation and integrate theirs as they released it first and 
started documenting it?


I just don't want to have 2 toolchains to support, that would be really 
terrible :(



/Orphis

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Unix makefile: concurrent build configurations

2016-08-23 Thread Florent Castelli

Well, I imagine we could have a shim that will automatically create 
sub-build directories when you specify a CONFIGURATION=... argument or 
just starts the build in there.
And if a build folder is missing but the configuration is declared, it 
would run CMake with similar startup arguments.
In practice, it would be the same generator, with some extra logic in 
the main Makefile.


/Florent

On 22/08/2016 13:55, Tobias Hunger wrote:

Hi Steve!

On Do, 2016-08-18 at 15:37 -0500, Steve Lorimer wrote:

New to this list, so apologies if it's been discussed before.

I'd like to know why it's not possible to have both debug and release mode
builds configured at the same time for Unix makefiles?

You can have an arbitrary number of configurations at once, all nicely separated
from each other in their own build directory. Nobody stops you from having
several build directories after all.


I am aware that some generators (eg VisualStudio) do allow this behaviour.
Why can I not have the same behaviour with Unix makefiles?

IMHO VisualStudio is rather broken in that regard. Please do not let the
insanity pass over to Makefiles! :-)

Best Regards,
Tobias



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Need ideas/opinions on third party library management

2016-08-16 Thread Florent Castelli

We have many smaller libraries and a few big ones like Boost.
It certainly takes a bit of time to setup, but it will save you a lot of time 
later.
It will keep your build scripts clean too as the user won’t have to know about
its dependencies setup. Just use “target_link_libraries” on the modern target
that was created and it will work.

Most of the 3rd party dependencies don’t work that way and they're quite painful
to use correctly. As in, if you miss to add the “add_definitions” they told you 
to use,
it will build, but source files might be used with a different preprocessor 
define and
you end up with two different implementations of the same class in the same 
binary.
It will crash in very mysterious ways. 

The most important point is *correctness*. If you experiment with tooling like
the Clang sanitizers, you’ll know that you can’t mix libraries that haven’t been
instrumented with instrumented code.
Best case the libraries are self-contained and will work all of the time.
Worst case, the libraries are mostly self-contained and will *not* work 
sometimes!

As an example, the Boost Unit Test Framework usually worked fine for us.
But sometimes, we had ASan triggering an issue in the constructor of the string
object for the test name. Our binary was built with ASan and Boost without.
When we built it from source, all the false positives went away.

I know that not a lot of people use them or have heard of them, but they are
a super important tool that will find TONS of real issues in your code the first
time you use them and we cannot do without.
Some people might rely on Valgrind Memcheck instead, but hey, this is 2016
and we like our tests to run fast(er)!

/Florent

> On 16 Aug 2016, at 14:41, Benjamin Ballet <bbal...@ivsweb.com> wrote:
> 
> Very interesting discussion, we have the same issues here.
> 
> Florent Castelli, how many third parties libraries do you use ? I think a 
> super build can be a very good solution but I'm wondering how much third 
> party code you have to build. Here we use OpenCV, with, boost, and poco, and 
> other things... So it may be too long.
> 
> I was personnaly considering having an hybrid solution : include small 
> libraries (like jsoncpp) and pre-build the other for each platforms.
> 
> 
> 2016-08-16 12:52 GMT+02:00 Florent Castelli <florent.caste...@gmail.com 
> <mailto:florent.caste...@gmail.com>>:
> At Spotify, we use CMake a lot for our large C++ library shared by all the 
> clients.
> After trying to build libraries for each platform and variant, we basically 
> gave up and we now
> use a super-build approach.
> 
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and 
> iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…) 
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost, we 
> had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build it 
> and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the flags 
> in your CMake files
> instead, which is still not good enough.
> 
> In the end, I looked at how Boost is actually built. And for most libraries, 
> it’s plain simple.
> A static library with a few files, some define, sometimes a platform specific 
> source file.
> What if instead of having an external build tool, I built it from CMake 
> instead?
> It would propagate all the build flags, target, instrumentation and compiler 
> information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary 
> distribution with the source
> distribution and it’s much easier. When people build our library for a 
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and patched 
> it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle 
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was 
> again effortless.
> 
> Overall, building boost takes 10s on our developers’ machines. The sources 
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but that’s 
> quite rare.
> 
> We try now to use the same approach for other libraries when we add them. 
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still 
> target version 2.8 (

Re: [cmake-developers] Need ideas/opinions on third party library management

2016-08-16 Thread Florent Castelli

At Spotify, we use CMake a lot for our large C++ library shared by all the 
clients.
After trying to build libraries for each platform and variant, we basically 
gave up and we now
use a super-build approach.

For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.
Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, MSan…) and 
really need
to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update Boost, we had 
to update
a lot of things.
I tried using ExternalProject and use b2 (build tool from Boost) to build it 
and instead of having
lots of build jobs with a mirror of the flags, you end up mirroring the flags 
in your CMake files
instead, which is still not good enough.

In the end, I looked at how Boost is actually built. And for most libraries, 
it’s plain simple.
A static library with a few files, some define, sometimes a platform specific 
source file.
What if instead of having an external build tool, I built it from CMake instead?
It would propagate all the build flags, target, instrumentation and compiler 
information from the main
build to it and just work.
I tried it and it worked in no time! We replaced our Boost 1.59 binary 
distribution with the source
distribution and it’s much easier. When people build our library for a 
different target, they don’t have
to download new binaries, they just reuse the same sources.
Later on, we found a bug in Boost 1.59 (fixed in later versions) and patched 
it. We updated our source
bundle and everything was smooth.
Much later on, we wanted to use 1.61. We just updated the source bundle again, 
the list of source
files or compilation flags for the libraries we use didn’t change. It was again 
effortless.

Overall, building boost takes 10s on our developers’ machines. The sources 
aren’t changed often,
so the cost is pretty low. It needs attention when we upgrade it, but that’s 
quite rare.

We try now to use the same approach for other libraries when we add them. Some 
of them are
already using CMake and it’s somewhat easier, but since most people still 
target version 2.8 (or 2.6...),
we find it better to rewrite the build scripts ourselves and use modern 
features (as in, everything is
a target that propagates requirements, we don’t propagate variables).
It makes it also much easier to build a library for another platform that 
wasn’t targeted by the original
project.

If people are interested, I could share the CMakeLists.txt file we use for 
Boost. It doesn’t build all
the libraries (some are hard like Context) and uses some internal macros, but 
it should be plain
simple to tweak for your use.

/Florent

> On 12 Aug 2016, at 21:59, Robert Dailey  wrote:
> 
> Hello,
> 
> There is an internal C++ product at the company I work for which I
> have written a series of CMake scripts for. This project actually has
> dependencies on several open source libraries, such as boost,
> freetype, openssl, etc.
> 
> Right now what we do is build each of these third party libraries *by
> hand*, once for every platform we support (Windows, Linux x86, Android
> NDK). Then we stuff the includes (headers) and libraries
> (static/shared) in a submodule and the primary code base's CMake
> scripts pull them in as interface targets.
> 
> This works well and is light-weight but is a pain when upgrading or
> changing libraries. It's a pain because if I want to upgrade boost, I
> have to build it up to 6 times (once for each platform and once for
> each configuration).
> 
> I've been thinking of a different approach for a while. I've done some
> toying around with the "Super Build" concept, where I have a separate
> CMake project that does nothing but use the ExternalProject module to
> build libraries in real time along with our project. So the order of
> operations would be as follows (for our automated build server):
> 
> 1. Clone our "Third Party" repository
> 2. Use CMake to generate & build the "Super Build" project (this
> builds boost, openssl, freetype, etc for the current platform).
> 3. Clone the main code base's repository
> 4. Use CMake to generate & build, using find_package() to refer to
> interface targets exported by those third party libraries built in
> step 2
> 
> Obviously this will make builds take significantly longer, because
> we're constantly rebuilding the same third party libraries over and
> over again. However, it virtually eliminates the maintenance burden
> for third party libraries because they are built inherently with
> everything else.
> 
> Note that I can't refer to pre-built libraries in our build
> environments because we need very specific control over the versions
> of our libraries as well as the toolchains that were used to build
> them. Also we may specifically build our libraries a certain

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

2016-08-06 Thread Florent Castelli

I'd say that you shouldn't do this unless you have tested it extensively 
with very long command lines, making sure that there is a response file 
fallback if it grows too much.
There are issues in CMake already on Windows with long command lines and 
having even longer ones is not going to help.


/Orphis

On 06/08/2016 01:51, Chaoren Lin via cmake-developers wrote:

From: Chaoren Lin 

This is consistent with the behavior of the Makefile generators.
Relative paths are difficult for an IDE to parse the output of a build
error.
---
  Source/cmNinjaTargetGenerator.cxx | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Source/cmNinjaTargetGenerator.cxx 
b/Source/cmNinjaTargetGenerator.cxx
index 855a243..5b4a55d 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -305,7 +305,7 @@ void cmNinjaTargetGenerator::WriteCompileRule(const 
std::string& lang)
vars.RuleLauncher = "RULE_LAUNCH_COMPILE";
vars.CMTarget = this->GetGeneratorTarget();
vars.Language = lang.c_str();
-  vars.Source = "$in";
+  vars.Source = "$IN_ABS";
vars.Object = "$out";
vars.Defines = "$DEFINES";
vars.Includes = "$INCLUDES";
@@ -529,8 +529,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
cmSourceFile const* source, bool writeOrderDependsTargetForTarget)
  {
std::string const language = source->GetLanguage();
-  std::string const sourceFileName =
-language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+  std::string const sourceFileName = this->GetSourceFilePath(source);
std::string const objectDir =
  this->ConvertToNinjaPath(this->GeneratorTarget->GetSupportDirectory());
std::string const objectFileName =
@@ -539,6 +538,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
  cmSystemTools::GetFilenamePath(objectFileName);
  
cmNinjaVars vars;

+  vars["IN_ABS"] = source->GetFullPath();
vars["FLAGS"] = this->ComputeFlagsForObject(source, language);
vars["DEFINES"] = this->ComputeDefines(source, language);
vars["INCLUDES"] = this->GetIncludes(language);



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Toward a more deterministic ninja generator

2016-06-15 Thread Florent Castelli

To this, I would add that you could also remove duplicates. They’re rare but 
can happen in some conditions and trigger warnings in Ninja.

/Florent

> On 14 Jun 2016, at 17:18, Nicolas Desprès  wrote:
> 
> Hi,
> 
> While working on something else I wrote this patch:
> https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19
>  
> 
> 
> It makes the ninja generator more deterministic by sorting the build edge's 
> inputs/outputs. It does not introduce any regression on my macbookpro.
> 
> This could help to fix issue #15968.
> 
> Regards,
> 
> -- 
> Nicolas Desprès
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] New module to verify that python libraries are available on the system

2016-05-03 Thread Florent Castelli


"exec(\"import sys\\ntry:\\n  import numpy\\nexcept:\\n  
sys.exit(0)\\nsys.exit(1)\")"

This seems to be great to check that numpy exists! You're probably 
missing a variable somewhere ;)


/Florent

On 03/05/2016 20:37, Francois Budin wrote:

Hello everyone,

I wrote a short macro for one project I work on to verify at 
configuration time that a python library is available on the system on 
which the project is configured. I have attached a patch to 
potentially integrate this new macro to CMake. I saw other people 
doing similar things in other projects, so it might be of interest to 
the community.

Hope this helps,

Francois




-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

2015-11-16 Thread Florent Castelli

It’s nice and I was thinking of doing the same!

But one there’s one thing that comes to mind. Some compiled libraries have 
dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those so we link 
everything properly?

And also maybe add the native dependencies for some modules that have one like 
maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

/Florent

> On 16 Nov 2015, at 15:01, rle...@codelibre.net wrote:
> 
> I have attached a patch to add imported targets to FindBoost, in the form
> of Boost:: (e.g. Boost::date_time) or Boost::Boost as a generic
> interface library for header-only components.
> 
> If this type of patch is acceptable, I would like to do this for a number
> of other modules for which I would like to be able to use so I export
> generic configurations for my own libraries, including XercesC, PNG, TIFF
> and a few others.  If that's OK, I'll follow up with patches for these
> modules.
> 
> 
> Regards,
> Roger Leigh<0001-FindBoost-Add-imported-targets.patch>-- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Listing source-tree files encountered

2015-07-18 Thread Florent Castelli

I've used that once and you end up with the relative path to the sources 
from the CMakeLists.txt.
If you're in another CMakeLists.txt, then you can't use the paths 
directly. I tried a few properties but I couldn't find any property to 
get the folder where the target was defined.


How do you get the full path?

/Orphis

On 17/07/2015 17:50, Brad King wrote:

On 07/15/2015 10:38 PM, Clifford Yapp wrote:

Lists that contains a verbatim collection of all path specifiers,
regardless of form, that are passed to the various add_* targets would
be enough, I think - it'd then be up to our own CMake logic to make
sense of it all.  I'm not hoping to push our whole
in-src-dir/distcheck system into mainstream CMake, just looking for a
way to achieve the current result without requiring the
built-in-command overrides - I think collecting raw lists of paths
supplied to targets is the key piece that is currently driving the
command overrides.

Once the list of all targets is available in a global property as
discussed in another branch of this thread, then you could loop
over that and check the SOURCES target property to get the list
of original path specifiers.  That would handle almost everything.
What would be left for your use case?

-Brad



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake

2015-06-30 Thread Florent Castelli

I just want to add that I also saw a colleague running in the issue
described in the beginning of the thread and that the version reported by
the Python module and the PythonLibs one were different strings, even
though the version was actually the same. It happened on latest Debian I
think.

How I discovered it? I had a check in my CMakeLists.txt that ensured the
strings were identical. It's the first time in years we saw it fail.

/Florent

On Tue, Jun 30, 2015 at 4:14 PM, Mark Moll mm...@rice.edu wrote:

 Brad,

 Thanks for the detailed explanation. I figured there were use cases not
 handled by my module. For instance, I hadn’t thought of cross-compilation.
 Since in my own project these unhandled cases haven't come up, I’ll stick
 with own module for now.

 With the existing modules it might be useful to add a check that if both
 PYTHON_VERSION_STRING and PYTHONLIBS_VERSION_STRING are defined, then they
 should be equal.

 Best,
 Mark



  On Jun 30, 2015, at 9:02 AM, Brad King brad.k...@kitware.com wrote:
 
  On 06/29/2015 09:41 PM, Mark Moll wrote:
  I have attached an alternative module that replaces the two current
  modules for finding python-related info. With the current modules
  it is easy to end up in a situation where the interpreter’s version
  and the library version do not match, which inevitably leads to
 problems.
 
  Thanks for working on this.  The need for a combined module has come
  up a few times.  The main reason it has not been done is because
  designing a combined module that meets all the use cases of the
  current two modules and deals with Python 2 and 3 is likely very
  tricky.
 
  Overall my main concern is that no logic from the existing modules
  is used in the proposed module.  The existing modules have worked
  for many projects for years and have a lot of knowledge built into
  them.  If we combine FindPythonInterp and FindPythonLibs then the
  results should be similar to finding both packages individually.
 
  The combined module should check/validate COMPONENTS requested in the
  call to find_package.  There could be Interp and Libs components such
  that the package can be found if one component is requested and the
  other is not available.
 
  When I've seen the need for a combined module discussed before,
  one issue that is commonly raised is that there should be separate
  FindPython2 and FindPython3 modules because the two languages are
  somewhat different and some projects may need to find both.  Then
  there could also be a FindPython that accepts either version for
  projects that can support either.  I'm not sure how variables should
  be named in each of the three modules, but their implementations
  should share as much code as possible.
 
  Further comments on the specific module implementation follow,
  though with the design requirements laid out above I doubt much
  of the code will be used as-is.  I think this thread should first
  focus discussion on interface design and not work on the actual
  code yet.
 
  Thanks,
  -Brad
 
 
  -
  Currently the module depends on running the python executable.  This
  can be allowed but cannot be required.  The module must be able to
  work when cross-compiling where the libraries come with an executable
  that may not run on the host.
 
  Please read the cmake-developer(7) documentation on find modules:
 
 
 http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#find-modules
 
  In particular please use the proper naming convention for cached
  v. result variables.  Also the module documentation needs to have
  proper .rst formatting.
 
  The PYTHON_EXEC variable should be called PYTHON_EXECUTABLE.
  (This may change depending on the v2/v3 discussion above.)
 
  For find_python_module, please provide documentation of the function
  using the .rst markup and .. command:: directive.  Also please look
  at using CMakeParseArguments rather than custom ARGC testing.
  -
  --
 
  Powered by www.kitware.com
 
  Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
  Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:
 
  CMake Support: http://cmake.org/cmake/help/support.html
  CMake Consulting: http://cmake.org/cmake/help/consulting.html
  CMake Training Courses: http://cmake.org/cmake/help/training.html
 
  Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
  Follow this link to subscribe/unsubscribe:
  http://public.kitware.com/mailman/listinfo/cmake-developers


 --

 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:

Re: [cmake-developers] Custom commands with Ninja on Windows

2015-06-15 Thread Florent Castelli

Alright, I'll see what I can do when I find some free time to work on this
then!

/Florent

On Mon, Jun 15, 2015 at 3:14 PM, Brad King brad.k...@kitware.com wrote:

 On 06/12/2015 06:01 AM, Florent Castelli wrote:
  So I've been thinking that on Windows, instead of concatenating
  everything, we should be a script that is run using a response
  file that just runs all the command with error checking.
  Eventually, we could reuse
 cmLocalVisualStudioGenerator::ConstructScript()
  for that matter.

 Yes, I think that would be a reasonable approach.

 Thanks,
 -Brad


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Custom commands with Ninja on Windows

2015-06-12 Thread Florent Castelli

Hi!

I'm having some issues with Ninja on Windows with long custom commands (or
actually a long succession of short commands appended to the same target).
The problem is that they get concatenated in one single command using  
 and it is pretty easy to go over the 8k command line size limit on
Windows.

So I've been thinking that on Windows, instead of concatenating everything,
we should be a script that is run using a response file that just runs all
the command with error checking. Eventually, we could reuse
cmLocalVisualStudioGenerator::ConstructScript() for that matter.

Any thought about this? Any hint for implementing this myself in the Ninja
generator? Do you think of another way to fix this issue?

Thanks,
/Florent
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] NMake Batch-Mode Rules (was: Inquiry on contribution to NMake generator)

2015-06-01 Thread Florent Castelli

At my company, we didn’t bother trying to use NMake.
We used the Visual Studio solution generator and the proper compilation flags 
and msbuild flags to build in parallel. This proved to speedup our builds quite 
a lot and was very easy to integrate.
The other solution you mentioned is “ninja” and sped up our builds even more. 
The msbuild tool is not smart enough and with a number of targets high enough 
and enough files per target, you can just generate n^2 parallel compilation 
processes, which can be counter productive. Though, you can manually specify 
the parallelism factor you want for both msbuild and cl.exe and you get decent 
results.

Give those a shot, NMake is deprecated in Visual Studio land and has been 
superseded by msbuild.

And if your devs complain about having to install some tools before compiling, 
just give them a script that downloads and setup CMake and Ninja on their 
system. It’s easy to do and should reduce the number of complaints!

Regards,
Florent

 On 01 Jun 2015, at 11:10, Nagy-Egri MĂĄtĂŠ Ferenc via cmake-developers 
 cmake-developers@cmake.org wrote:
 
 Thanks Brad for the detailed description. From what I’ve read about the 3 
 level makefile system, it should be pretty straightforward to implement 
 batch-mode support.
 
 Actual compilation takes place only in the last level, and throughout 
 generation, this is the point where all the compilation options are present. 
 Obtaining a list of files with identical compiler switches might be tricky. 
 Depends on how CMake handles this in code internally. I’ll see once I dive 
 into code. Deferred generation of the makefile is not nice, but might be the 
 only way. Handling the exact location of the object files might be another 
 property source files must match.
 
 As far as I’ve seen NMake is not able to call multiple makefiles in parallel, 
 so source-level parallelism might be the most NMake could do, but for large 
 projects that could be sufficient.
 
 Feladó: Brad King mailto:brad.k...@kitware.com
 Elküldve: ‎szerda‎, ‎2015‎. ‎május‎ ‎27‎. ‎20‎:‎13
 Címzett: Nagy-Egri MC!tC) Ferenc mailto:csiga.b...@aol.com
 Másolat: cmake-developers@cmake.org mailto:cmake-developers@cmake.org
 
 On 05/27/2015 01:33 PM, Nagy-Egri MC!tC) Ferenc via cmake-developers wrote:
  like to see the NMake generator finally support multicore builds by
  adding Batch Mode support to the generated makefiles.
 
 For reference, Batch-Mode Rules are documented here:
 
  https://msdn.microsoft.com/en-us/library/f2x0zs74.aspx
 
 They support specifying multiple source files to a single cl invocation,
 as in
 
  cl -c src1.cpp src2.cpp
 
 instead of
 
  cl -c src1.cpp
  cl -c src2.cpp
 
 Any multi-core utilization occurs inside cl and NMake is not aware of it.
 
  I have read on the CMake user mailing list, that the problem with
  Batch Mode support, is that it is not trivial to implement.
 
 It is very hard to implement and may not be possible at all.  See below.
 
* What is the design of the NMake generator in CMake?
* What is the pourpose of having so many makefiles?
 
 http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F
 
* What is the reason why it is not trivial to implement batch mode?
 
 The main reasons are:
 
 * CMake generates a separate compilation line for each source in each
   target and the flags may differ across sources and targets.  CMake
   does not use pattern rules for any make backend.
 
 * CMake needs to control the location of the object files and cl does
   not allow this when more than one source is given.
 
 Implementing batch mode rules would require teaching the generator to
 somehow recognize when a group of sources are all built with the same
 flags and generate a batch mode rule that matches exactly those sources
 and no others (likely the hardest part).  This grouping would also have
 to account for the names that cl generates for the object files to avoid
 conflicts within a group.  I do not know if generating a proper batch mode
 rule is possible in general.
 
* Where should I start browsing the source files?
 
 One place is Source/cmLocalUnixMakefileGenerator3.cxx but there is no
 specific spot to make a change like this.  It would likely involve
 major refactoring.
 
 One can achieve multi-core builds without third-party tools by using
 the VS IDE generators.  It is still possible to build from the command
 line with these.
 
 -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

Re: [cmake-developers] A CMAKE_EMULATOR variable

2015-03-04 Thread Florent Castelli

Sometimes, it’s not just about an emulator but a wrapper script that can run 
the target binary on a remote host or with the right environment (or use 
valgrind, helgrind, whatevergrind...).

I’d be nice to have the option in ctest to use some script to run a test 
program and an option to set it from CMake globally or when running ctest 
directly.

/Orphis

 On 04 Mar 2015, at 17:06, Matt McCormick matt.mccorm...@kitware.com wrote:
 
 Yes:
 
 it emulates the target system when cross-compiling, and
 executables built for the target system can be run when passed to the
 emulator.
 
 is exactly correct.
 
 Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve
 the ambiguity.  Or...
 
 Thanks,
 Matt
 
 On Wed, Mar 4, 2015 at 6:49 AM, David Cole dlrd...@aol.com wrote:
 What does CMAKE_EMULATOR emulate?
 
 From its name, it sounds like it emulates CMake. But from your description,
 I'm thinking that doesn't make sense... Because you actually run CMake and
 pass it CMAKE_EMULATOR. So it must be emulating something else while running
 CMake?
 
 I'm guessing it emulates the target system when cross-compiling, and
 executables built for the target system can be run when passed to the
 emulator? Is that right?
 
 
 D
 
 
 
 On Wednesday, March 4, 2015, Matt McCormick matt.mccorm...@kitware.com
 wrote:
 
 Hi,
 
 I have pushed to stage [1] support for a CMAKE_EMULATOR variable to
 help when cross-compiling.  The goal is to improve cross compiling
 with CMake by making it easier to build and run tests.  In principle,
 the commands
 
  cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake
 -DCMAKE_EMULATOR=/path/to/emulator ~/src/project
  cmake -D Experimental
 
 are all that is needed generate a dashboard report, complete with test
 results.  This should inch C/C++ closer to being the write once, run
 anywhere languages :-).
 
 The emulator is used to run try_run results, which avoids manual
 population of TryRunResults.cmake.  This can be a painful,
 time-consuming process otherwise.
 
 It is also used to run tests on executables that are built for the
 target system.  Without this approach, it is difficult to know which
 tests should be executed on the target system.  Tests are often passed
 absolute paths to input on the host system.  The use of an emulator is
 a way to avoid complexities and transfer overhead related to
 reproducing the host filesystem on the target filesystem to run the
 tests.
 
 
 With some fixes to ITK [2], this was used to build and test for four
 cases of interest.
 
 The emulator approach works best with MinGW and WINE to build and test
 on Linux for Windows [3].
 
 The qemu-arm emulator provided by QEMU User Mode can be used with the
 Android NDK toolchain [4]. A gotcha is that Android tries to be fancy
 and uses its own dynamic loader.  To get around this, I tested with
 completely static executables.  Also, QEMU User Mode does not
 currently support multi-threading well, so tests were run
 single-threaded. An alternative approach may be to use an emulator
 script that is a wrapper around adb.
 
 The qemu-arm emulator was used again with the Raspberry Pi toolchain
 [5].  A symbolic link was created in the expected location for
 ld-linux-armhf.so.3, and dynamic loading works.  To run the tests,
 LD_LIBRARY_PATH was populated with the path to libc and libstdcxx.
 
 One of the most interesting combinations is the Emscripten toolchain
 with NodeJS as the emulator [6]. There are some WIP workarounds to get
 Emscripten to configure cleanly for scientific libraries [7], and code
 had to be injected into the test driver to mount local filesystems for
 node, but this works surprisingly well.
 
 
 Testing and feedback are appreciated.
 
 Thanks,
 Matt
 
 
 [1]
 http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator
 
 [2] https://github.com/thewtex/ITK/tree/cmake-emulator
 
 [3] https://open.cdash.org/buildSummary.php?buildid=3694578
 
 [4] https://open.cdash.org/buildSummary.php?buildid=3694810
 
 [5] https://open.cdash.org/buildSummary.php?buildid=3694810
 
 [6] https://open.cdash.org/buildSummary.php?buildid=3705525
 
 [7] https://github.com/thewtex/emscripten/tree/test-big-endian
 --
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers
 -- 
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ

Re: [cmake-developers] iOS support

2014-10-01 Thread Florent Castelli

Thanks for the detailed information.
My hackweek starts on Monday and I'll start working on these issues then.
I'll work on finding a way to unify toolchain files for simulator and
devices first. I don't think I'll try to work on iOS8 features since my
company is shipping for iOS6 and there are so many things to do :)
Though, I'm not really an iOS developer, there's probably a ton of things
I'll miss. But I have great devs in my company and I'm sure it'll be okay!

I'll keep you updated of my progress during the week and hopefully, I won't
have to call for help here too often :)

/Orphis
On 1 Oct 2014 01:42, Eric Wing ewmail...@gmail.com wrote:

 Thought of one more.
 I hate how the top, default target is ALL_BUILD. This is problematic
 for both Xcode and Visual Studio because when you use the big giant
 run button in the UI, the IDE is confused because ALL_BUILD is an
 aggregate target and not a real thing that can be run. At least for
 Xcode, a bunch of options change dynamically based on the type of
 target selected and building/launching to the device/simulator is not
 an option when on an aggregate target.

 It's an annoyance because it interferes with the normal workflow for
 those familiar with the IDEs. And it's an annoyance for those who are
 not familiar with the IDEs because the big giant buttons do nothing
 and they don't understand the IDEs well enough on how to correct the
 issue.

 (It's also more work invoking xcodebuild and msbuild because you can't
 rely on the default targets.)

 Thanks,
 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] iOS support

2014-09-23 Thread Florent Castelli

Hi!

My company is organizing soon a hack week where each employee is able to
work on any project he wants. So, I've decided to work with Cmake and
improve support for iOS to help the product team getting rid of manual
project files, constant merge conflicts and bad project file documentation,
while improving our tooling possibilities (all that with Cmake!).

I've had a quick look at the first issue that popped into my mind the other
day and fixed try_compile by adding another variable to set the executable
type in the generated project (it has to be MACOSX_BUNDLE) and fixing the
search path for the resulting binary.
So this is now working... Providing we are targeting the simulator.
Due to the nature of Xcode projects that can easily target either the
simulator or devices, thus using different compilation flags, the resulting
projects aren't working in both case. There are conflicts between some
options like the minimum iOS version target and the minimum iOS simulator
target for example (which you need to build the try_compile binaries
without signing them).
Also, the Xcode support is very OSX focused and all variables have MACOSX
in their name, which is confusing.

So, has anyone worked on similar issues and can suggest a way to progress
and improve support for iOS?
In the end, I'd like to have a working Xcode project with separate settings
for both simulator and device, Cmake compiler flag detection working, and
possibly later Make/Ninja projects working too.

Regards,
/Orphis
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] iOS support

2014-09-23 Thread Florent Castelli


On 23 Sep 2014, at 16:56, Bill Hoffman bill.hoff...@kitware.com wrote:

 
 That said it would be really cool to beef up the xcode support enough to
 be able to create an actual ios app.  I have not dug into that enough.
 Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will
 look into this try_compile COPY_FILE issue today and get back to the list.
 
 It would be great if you could get an example/Test in place that builds
 an app for a device and works with Xcode and for a stretch goal also
 works with makefiles or ninja.
 
 Couple of more things.
 
 Much of the stuff found in these toolchains:
 https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake
 https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake
 https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake
 Should be in Platform files.  If we created ios platform files we could 
 remove most of the stuff from those toolchain files.  This would be a great 
 thing to work on.
 

The problem is that I want a project that is usable by developers directly and 
you can't really force them to target just the simulator. It should work for 
targeting both simulator and real device. So having a generic iOS toolchain 
that can generate both in one project is a requirement for me.
Generating projects for Makefiles or Ninja would probably require a dedicated 
toolchain though (or proper platform files indeed), but that can be done later.

 Also, Robert M reminded me that there is a test that could be extended as 
 this stuff is developed:
 
 https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it
 already builds targeting the iphone simulator.
 
 -Bill
 

Nice, I will have a look!

I also have a couple of patches for finding the binary during a try_compile 
that works with my other change to have an extra variable for the 
add_executable and I would need to change it.
It's mostly changing cmCoreTryCompile::FindOutputFile() and adds / + 
targetName + .app/Contents/MacOS to the searchDirs.

I'll try to pickup those toolchain files though and see how they work for me 
soon. I'll probably have some options to override a few things and make it find 
the compiler properly. Right now, it's hardcoding /usr/bin/clang and that's a 
no go :) (it should be found in the path or through DEVELOPER_DIR eventually). 
Not forcing the compiler would be sweet too (but that requires the try_compile 
fixup first) as it means we could use ccache or an alternative compiler (for 
reasons).

/Orphis

 
 -- 
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community. For more 
 information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it

2014-07-01 Thread Florent Castelli

When cross compiling, toolchains won't have install_name_tool,
which is provided by Xcode and command line tools on OSX.
This is a Mach-O specific utility and not required on all platforms.
---
 Modules/CMakeFindBinUtils.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modules/CMakeFindBinUtils.cmake b/Modules/CMakeFindBinUtils.cmake
index 829b6ff..5b5bda8 100644
--- a/Modules/CMakeFindBinUtils.cmake
+++ b/Modules/CMakeFindBinUtils.cmake
@@ -68,7 +68,7 @@ endif()


 # on Apple there really should be install_name_tool
-if(APPLE)
+if(CMAKE_PLATFORM_HAS_INSTALLNAME)
   find_program(CMAKE_INSTALL_NAME_TOOL NAMES install_name_tool HINTS 
${_CMAKE_TOOLCHAIN_LOCATION})

   if(NOT CMAKE_INSTALL_NAME_TOOL)
--
2.0.0



0001-Only-search-for-install_name_tool-if-the-toolchain-h.patch
Description: Binary data
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Compile targets affected by changeset

Re: [cmake-developers] Compile targets affected by changeset

Re: [cmake-developers] Support for unified headers in Android NDK

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

Re: [cmake-developers] Unknown Imported & Global libraries

[cmake-developers] Unknown Imported & Global libraries

Re: [cmake-developers] Android variables

Re: [cmake-developers] Android variables

Re: [cmake-developers] Android variables

Re: [cmake-developers] Add property to get all linked libraries including transitive ones

Re: [cmake-developers] CMake integration in Gradle (Android Studio)

Re: [cmake-developers] Android Support

Re: [cmake-developers] Android Support

Re: [cmake-developers] Unix makefile: concurrent build configurations

Re: [cmake-developers] Need ideas/opinions on third party library management

Re: [cmake-developers] Need ideas/opinions on third party library management

Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.

Re: [cmake-developers] Toward a more deterministic ninja generator

Re: [cmake-developers] New module to verify that python libraries are available on the system

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

Re: [cmake-developers] Listing source-tree files encountered

Re: [cmake-developers] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake

Re: [cmake-developers] Custom commands with Ninja on Windows

[cmake-developers] Custom commands with Ninja on Windows

Re: [cmake-developers] NMake Batch-Mode Rules (was: Inquiry on contribution to NMake generator)

Re: [cmake-developers] A CMAKE_EMULATOR variable

Re: [cmake-developers] iOS support

[cmake-developers] iOS support

Re: [cmake-developers] iOS support

[cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it

31 matches

Site Navigation

Mail list logo

Footer information