Re: [cmake-developers] Xcode source file type

2017-05-15 Thread James Touton
Thanks, guys; I'll investigate and see what I can do.

On Mon, May 15, 2017 at 6:06 AM, Brad King  wrote:

> On 05/14/2017 05:42 PM, Gregor Jasny via cmake-developers wrote:
> > I'd welcome any attempts to simplify the Xcode generator. But before I'd
> > ack such a PR I'd like to know why this functionality was added in the
> > first place. CMake still supports (does not actively break) Xcode 3. If
> > there is no answer to that question: maybe you could test and limit your
> > changes to a newer Xcode version (like 5 or above).
>
> Run
>
> ```
> $ git log -SlastKnownFileType -- Source/
> ```
>
> to see a history for this setting.  Some investigation may be
> needed to determine what is needed for current Xcode versions.
> The setting could easily be made conditional on the Xcode version.
>
> -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] Wrongly assuming lib/ is IsImplicitDirectory for runtime-paths

2017-05-15 Thread Brad King
On 05/15/2017 03:28 AM, Patrick Boettcher wrote:
> To this list somewhere the lib/-path located next to the
> compiler-bin/-path has been added.
[snip]
> What can I do? Is this a bug in cmake or in my setup?
> Why is this path considered implicit?

CMake tries to detect the implicit link directories used by the
compiler front-end when driving the linker.  See results in any
build tree:

```
$ grep IMPLICIT CMakeFiles/*/CMake*Compiler.cmake
```

The `Modules/CMakeParseImplicitLinkInfo.cmake` file contains the
code that does this.  It is called while detecting the compiler.

The assumption is that running `c++ foo.cpp && ./a.out` will work
with no special runtime paths explicitly added.  The toolchain
should be configured to add its own implicit link directories to
the runtime path of binaries it links, or the environment should
otherwise be configured such that the dynamic loader looks there.

-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_TEST_XXX variables

2017-05-15 Thread Brad King
On 05/13/2017 08:55 PM, Craig Scott wrote:
> only set on the CMake command line by CI builds or similar,

Correct.  We need a way to activate such tests only on machines
where we expect them to work.  It would be nice to have something
better but I'm not sure what else we can do.  We used to try to
add tests for find modules automatically but that ends up needing
to run the find modules as part of configuring CMake, giving the
false appearance that CMake actually needs all those packages and
possibly breaking on bad ones.  The GTK2 tests still have this
problem.

-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] ;-list in docs

2017-05-15 Thread Brad King
On 05/13/2017 06:43 PM, Jean-Michaël Celerier wrote:
> On Sat, May 13, 2017 at 5:39 AM, Craig Scott wrote:
>> ;-list
> It's a shorthand for semicolon-separated list : 
> https://cmake.org/cmake/help/v3.8/command/separate_arguments.html?highlight=semicolon

Yes.  In documentation that has been modernized we use

:ref:`;-list `

to link here:

 https://cmake.org/cmake/help/v3.8/manual/cmake-language.7.html#lists

-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] Xcode source file type

2017-05-15 Thread Brad King
On 05/14/2017 05:42 PM, Gregor Jasny via cmake-developers wrote:
> I'd welcome any attempts to simplify the Xcode generator. But before I'd
> ack such a PR I'd like to know why this functionality was added in the
> first place. CMake still supports (does not actively break) Xcode 3. If
> there is no answer to that question: maybe you could test and limit your
> changes to a newer Xcode version (like 5 or above).

Run

```
$ git log -SlastKnownFileType -- Source/
```

to see a history for this setting.  Some investigation may be
needed to determine what is needed for current Xcode versions.
The setting could easily be made conditional on the Xcode version.

-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] Does JOB_POOL_[COMPILE|LINK] work with custom_target?

2017-05-15 Thread Ben Boeckel
On Mon, May 15, 2017 at 11:46:37 +0200, Eric Noulard wrote:
> No answer whatsoever on this?

I don't think it is supported right now.

> I'd like to be able assign some custom targets to a ninja job pool.
> If I were to implement the feature would it be acceptable upstream ?

I think it'd be fine.

--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


Re: [cmake-developers] Does JOB_POOL_[COMPILE|LINK] work with custom_target?

2017-05-15 Thread Eric Noulard
Hi all,
No answer whatsoever on this?

Initial contributor of Ninja job pool appears to be Peter Kümmel:
commit 7605e37aabae2678e5696a75e84aced2e84f9037
Author: Peter Kümmel 
Date:   Sat Nov 23 10:49:36 2013 +0100


I'd like to be able assign some custom targets to a ninja job pool.
If I were to implement the feature would it be acceptable upstream ?

Eric

2017-05-05 16:16 GMT+02:00 Eric Noulard :

> Hi all,
>
> We have a bunch of custom_target and a subset of them should be run in
> sequence.
> So we tried to define:
>
> set_property(GLOBAL PROPERTY JOB_POOLS exclusive=1)
>
> and then:
>
> set_property(TARGET my_custom_target PROPERTY JOB_POOL_COMPILE exclusive)
> set_property(TARGET my_custom_target PROPERTY JOB_POOL_LINK exclusive)
>
>
> This does not seem to reach build.ninja ?
>
> The new pool is defined but the concerned custom targets are never
> assigned to the pool?
>
> May custom target be assigned to a ninja pool?
> If so how can we do that?
> --
> Eric
>



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Wrongly assuming lib/ is IsImplicitDirectory for runtime-paths

2017-05-15 Thread Patrick Boettcher
Hi list,

This is a follow-up of my problem I discussed with myself on the
cmake-mailing list: "CLANG vs GCC when linking executables".

I found the root-cause of this problem:

When constructing the rpath-arguments cmake is using an
cmOrderDirectories called OrderLinkerSearchPath to which all
the runtime-libraries via AddRuntimeLibrary() have been added.

In AddRuntimeLibrary() it checks whether the library-path is an
implicit directory.

To this list somewhere the lib/-path located next to the
compiler-bin/-path has been added.

This works well if the compiler is installed in /usr/bin
because /usr/lib is present in the system's loader-configuration.

In my case I have locally built a compiler and in the lib/-dir next to
the bin/-dir I installed other libraries. When now linking with one of
them (via an IMPORTED library), cmake does not add the rpath because it
assumes lib/ is implicitly used by the loader (or something else?).

What can I do? Is this a bug in cmake or in my setup? Why is this path
considered implicit?

best regards,
--
Patrick.
-- 

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