Re: [cmake-developers] Emit link commands to file?

2016-04-09 Thread Tamás Kenéz
For the "Unix Makefiles" generator, there's already a link.txt in
/CMakeFiles/.dir

Tamas
-- 

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] -isystem suppresses warnings from user header

2016-04-07 Thread Tamás Kenéz
Thanks! I missed that property.
Tamas

On Thu, Apr 7, 2016 at 4:13 PM, Brad King <brad.k...@kitware.com> wrote:

> On 04/07/2016 10:03 AM, Tamás Kenéz wrote:
> > CMake uses "-isystem" on the compiler command line for the
> > INTERFACE_INCLUDE_DIRECTORIES of imported libraries.
> >
> > Question: is this the intended behaviour?
>
> Yes.  See discussion here:
>
> * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7533
>
> and implementation here:
>
> * Always consider includes from IMPORTED targets to be SYSTEM.
>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb
>
> > Can I force the -I flag somehow for my library?
>
> Look at these:
>
> *
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
> * https://cmake.org/cmake/help/v3.5/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html
>
> -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] -isystem suppresses warnings from user header

2016-04-07 Thread Tamás Kenéz
Environment: CMake 3.5, linux, g++

CMake uses "-isystem" on the compiler command line for the
INTERFACE_INCLUDE_DIRECTORIES of imported libraries.

Unfortunately including a header via an isystem path suppresses warnings
emitted from the header, such as warnings caused by expansions of macros
defined in that header.

Example: I have a printf-like LOG(...) macro which expands to a function
marked as printf-like. The -Wformat warnings are suppressed if the
containing log.h is found on isystem path.

Question: is this the intended behaviour? Can I force the -I flag somehow
for my library? (I'm aware of CMAKE_INCLUDE_SYSTEM_FLAG_CXX but I don't
want to modify all the client projects that uses my library.)

Or is it bug?

Thanks,
Tamas
-- 

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

2016-03-19 Thread Tamás Kenéz
Ruslo, I think we all could argue both against and for implementing
cmake-ini files inside the cmake command. I mean I'm also aware of all the
pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own cmake-wrapping
extension script works fine, that's why I thought you would not lose
anything with that.

>> git commit --author="John Doe" --email="john@example.com"
<john@example.com> --branch="master"
>> git push --remote="git://awesome.example.com"
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov <ruslan_bara...@yahoo.com>
wrote:

> On 15-Mar-16 02:42, Tamás Kenéz wrote:
>
> I also doubt this belongs to upstream. But you could write a single,
> generic script which forwards its arguments to cmake and also accepts and
> processes the additional parameters along the way. I don't think we'd lose
> anything:
>
> cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS
>
> This is the approach I took as I needed features like you described. But
> if there would be a mature, versatile, community-tested script I'd be
> willing to use it and contribute to it.
>
> As you can see I'm already using script `build.py` and there is not enough
> power for now (even if it extends CMake basic functionality a lot) so I was
> thinking to introduce global/local ini-configuration file anyway. Then I
> realize that most of the `build.py` functions can be implemented in such
> ini-configuration. So why not use CMake? Why for example not extend CMake
> GUI with this feature support? Why do users need to install some extra
> tools instead of just one?
>
> Global/local configuration files in not something special. Git for example
> has same system, yes it increase complexity but literally every user store
> setting there.
> Just imagine you have to write something like this every commit + push:
>
> > git commit --author="John Doe" --email="john@example.com"
> <john@example.com> --branch="master"
> > git push --remote="git://awesome.example.com"
>
> This is a complete nonsense!
>
> So I'm planning to make a fork anyway and do some experiments even if it
> will not accepted to upstream.
>
> Ruslo
>
>
> Tamas
>
> On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
> <cmake-developers@cmake.org>cmake-developers@cmake.org> wrote:
>
>> On 14-Mar-16 21:59, Brad King wrote:
>>
>>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>>
>>>> I guess it is a well known fact that cmake command is almost never
>>>> executed alone and for non-trivial examples usually hold some extra
>>>> arguments (home directory, build directory, verbosity level, toolchains,
>>>> options, ...). Also I guess that such commands doesn't change from
>>>> day-to-day development process and an obvious way to reduce typing is to
>>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>>> one).
>>>>
>>> Sorry, I don't think something like this belongs upstream.  It can easily
>>> be done with shell aliases or other custom scripts.
>>>
>> I've got quite opposite experience. It's hard to say that family of
>> custom scripts (+ a lot of environment variables in .bashrc)  is an "easy
>> shell scripting", example:
>> *
>> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>>
>>We shouldn't increase the complexity of the CMake command line
>>> interface further.
>>>
>> To be clear this feature required only one new CMake option. The rest is
>> responsibility of some pre-build parsing module.
>>
>> In general I feel sad that CMake will not became more user-friendly in
>> this exact part. Though the only proves of my point that can be provided
>> here is a users experience. Since I don't see any feedback here I'm out of
>> arguments...
>>
>> Ruslo
>>
>> --
>>
>> 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/hel

Re: [cmake-developers] CMake aliasing system

2016-03-14 Thread Tamás Kenéz
I also doubt this belongs to upstream. But you could write a single,
generic script which forwards its arguments to cmake and also accepts and
processes the additional parameters along the way. I don't think we'd lose
anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. But if
there would be a mature, versatile, community-tested script I'd be willing
to use it and contribute to it.

Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
cmake-developers@cmake.org> wrote:

> On 14-Mar-16 21:59, Brad King wrote:
>
>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>
>>> I guess it is a well known fact that cmake command is almost never
>>> executed alone and for non-trivial examples usually hold some extra
>>> arguments (home directory, build directory, verbosity level, toolchains,
>>> options, ...). Also I guess that such commands doesn't change from
>>> day-to-day development process and an obvious way to reduce typing is to
>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>> one).
>>>
>> Sorry, I don't think something like this belongs upstream.  It can easily
>> be done with shell aliases or other custom scripts.
>>
> I've got quite opposite experience. It's hard to say that family of custom
> scripts (+ a lot of environment variables in .bashrc)  is an "easy shell
> scripting", example:
> *
> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>
>We shouldn't increase the complexity of the CMake command line
>> interface further.
>>
> To be clear this feature required only one new CMake option. The rest is
> responsibility of some pre-build parsing module.
>
> In general I feel sad that CMake will not became more user-friendly in
> this exact part. Though the only proves of my point that can be provided
> here is a users experience. Since I don't see any feedback here I'm out of
> arguments...
>
> Ruslo
>
> --
>
> 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] CMake Daemon blog

2016-01-25 Thread Tamás Kenéz
That's great and really does open a new world for IDEs!
Tamas

On Sun, Jan 24, 2016 at 11:44 PM, Stephen Kelly  wrote:

> Hi,
>
> I just made a blog and video about the advanced features and possibilities
> that a daemon mode for CMake can bring:
>
>  https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/
>
> I'll make the code available by the end of the week. I still want to clean
> it up a little bit first :).
>
> Thanks,
>
> Steve.
>
>
> --
>
> 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] install(EXPORT) with PRIVATE dependency: possible bug

2016-01-14 Thread Tamás Kenéz
It seems that the names of the PRIVATE dependencies of a library are not
affected by either the NAMESPACE option or the EXPORT_NAME property. A
minimal example:

add_library(one STATIC ...)
add_library(two STATIC ...)
target_link_libraries(two PRIVATE one)
install(TARGETS one two EXPORT targets DESTINATION lib)
install(EXPORT targets NAMESPACE ns:: DESTINATION cmake)

The generated `targets.cmake` describes the dependency relation with:

set_target_properties(ns::two PROPERTIES
  INTERFACE_LINK_LIBRARIES "\$"
)

That is, it uses `one` instead of `ns::one`. Changing the EXPORT_NAME of
`one` has no effect either.

It works find if I replace PRIVATE with PUBLIC or INTERFACE (of course
there'll be no more LINK_ONLY genexp in that case).

Is this really a bug or did I miss something? I also searched Mantis and
haven't found anything related.

Tamas
-- 

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

2016-01-14 Thread Tamás Kenéz
Looking at what kind of mistakes the newcomers make, I think it's rather
the global workflow and the roles of certain key variables/properties they
don't get.

At first their problem is not that they can't make a for-loop or increment
a variable. It's that they don't understand how the build and install
phases relate to each other, how to organise the files and targets of a
multi-target project, how to connect two projects. These would be just as
difficult to grasp in Python or Lua as it is in CMake-script.

I support replacing the CMake language but in order to lower the barrier I
think 10-20 nice, minimal sample projects would be more important.

Tamas


On Wed, Jan 13, 2016 at 2:14 PM, Charles Huet 
wrote:

> I don't think this is a dumb question, actually this is part of the
> problem I think would be resolved whit a new language.
>
> The barrier of entry to using CMake is too high in my opinion, and I think
> using an existing language would lower it *a lot*.
>
> Thanks for sharing :)
>
>
> Le mer. 13 janv. 2016 à 10:59, yann suisini  a
> écrit :
>
>> Hi,
>>
>> I'm a new user of CMake, but I just want to express my newcomer point of
>> view.
>> Honestly , I can feel the power of CMAKE, but it's a real pain to learn
>> ...
>> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
>> the end the CMAKE description is longer than the one I built directly in
>> Ninja.
>> I had to write a python script to parse my eclipse project xml to create
>> a list of sources files usable by CMAKE.
>> The first thing I thought was: why this is not a part of cmake ? And the
>> second thing was : why not using the scripting power of an existing
>> language like Python(or other one)
>> and add CMAKE as a framework / library ?
>> Probably a dumb question ! :)
>>
>> Yann
>>
>> 2016-01-13 10:34 GMT+01:00 Charles Huet :
>>
>>> Hi,
>>>
>>> > * There is a lot of code out there in the current CMake language so I
>>> do not
>>>   think it is realistic to drop it.  I'm not proposing that this change.
>>>
>>> I am. (more below)
>>>
>>> > * Many projects build elaborate macro/function systems in the CMake
>>> language
>>>   in order to end up with a declarative specification listing the actual
>>>   source files, dependencies, and usage requirements.  I'd like to offer
>>>   an alternative to this.
>>>
>>> In my experience, most of the elaborate macros/functions come either
>>> from a misunderstanding of some of CMake's internals (scope, link
>>> debug/release libs, etc) or to circumvent some shortcoming of the CMake
>>> language (e.g. no return value for functions).
>>>
>>> >  I'd like to improve this by *optionally* moving part of the
>>> specification
>>>   to a (stateless) declarative format that IDEs can load/edit/save
>>> directly
>>>
>>> Split the buildsystem in two different languages ? Would the declarative
>>> part be in a different file ?
>>> Also, the declarative part in my opinion must take advantage of the
>>> language.
>>> For instance, add a source file only for WIN32 systems should be easy in
>>> said declarative format.
>>> Using a custom language (based on JSON for instance) would mean to add
>>> conditionals, which comes back to making a custom language again.
>>>
>>>
>>> To come back to my first point, I understand completely that this would
>>> be a tremendous change, and the transition would be difficult to say the
>>> least. But I think it would be more than worth it in the long term.
>>>
>>> > The moment you make CMake scriptable in more than one language, you
>>> are forcing
>>> > every CMake user to learn that additional language because sooner or
>>> later he
>>> > will step into a third-party that is using that additional language.
>>>
>>> What I have in mind is to deprecate the current CMake language and
>>> replace it with another language. So there would be a transition period,
>>> but in the end there would only be one language again, and a better one.
>>>
>>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>>> would not need learn a new language (or at least learn one that has many
>>> resources, and can be used for other purposes).
>>> Old-timers would have to learn a new language (or maybe not, most
>>> programmers I know have played a bit with python to automate simple tasks),
>>> but this would be easier than learning CMake was, since there are
>>> established rules and a more consistent design to it.
>>>
>>> Of course I'm not saying this should happen overnight, nor am I saying
>>> this *must* happen, but I think discussing it can only be beneficial.
>>>
>>> I've seen lots of people wonder how to make their CMake scripts more
>>> efficient, and currently this is a very difficult thing to do, since there
>>> is no profiling possible.
>>> And who can say they never spent way too much time trying to understand
>>> why a variable was not correctly initialized ? When the configure step

Re: [cmake-developers] Using CMake as a library from Python

2016-01-04 Thread Tamás Kenéz
Charles,

I'd like to comment on a minor issue:

CMakeLists.txt files don't specify user-specific data like source and build
dirs (for a reason) yet your POC listfile contains this line:

cmake.init("Ninja", "/media/dev/src/cmaketest",
"/media/dev/build/cmaketest")

which sets the source and build directories. Is this some temporary
solution for the POC only?

Tamas

On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet  wrote:

> Hi,
>
> Because of the above, I worry that you are basing your work on an old
>> version of CMake. As of April 2015 cmState is used as the interface to the
>> cache.
>
>
> Yeah, that is sadly right. I wanted to rebase on master before publishing,
> thinking it should not be too hard, and I have lots to re-do, mostly
> understand how things are done now.
>
> I did something similar some years ago with QML instead of python, so it
>> sounds interesting to me.
>
>
> I'm trying to be as declarative as possible, because really like how
> readable simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> My guess is that you are using python to instantiate a cmAddLibraryCommand
>> and then executing it.
>
>
> Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all the commands, and it seemed backwards to me to wrap them.
>
> Even much of cmMakefile shouldn't be used by a new language. Instead
>> certain
>> parts of cmMakefile should be extracted as other classes
>> (cmVariableExpander
>> which should have the ExpandVariablesInString and ConfigureString stuff,
>> cmMessenger for the IssueMessage stuff, some other class for the
>> CompileFeature stuff etc). Then cmMakefile would be just about executing
>> and
>> scoping the CMake language. A new language would not need that, but would
>> use the refactored extracted classes.
>
>
> Ah, this is very interesting, thanks.
>
>
> Having said all that, Brad favors Lua I believe, and he favors a different
>> approach (which no one is working on as far as I know) to adding a new
>> language. So wait to hear from him to know whether it is something that
>> would be upstreamable.
>
>
> Have any details on the approach in question ? SWIG would allow for Lua
> bindings as easily, but I don't think having multiple languages would be a
> good idea.
> I went with Python because I'm familiar with it and have already written
> bindings for it with SWIG. Also, buildbot is written in python and it could
> provide a really interesting integration I think.
>
> I would guide/support you in refactoring cmake as needed. The refactoring
>> part would definitely be upstreamable. I would very much like to see a
>> proof
>> of concept alternative language even if that wasn't upstreamed. It would
>> prove that another language is possible, and that's one of the steps to
>> replacing the current cmake language I think.
>
>
> I will need to work on it to make it work again with master, but I'll try
> and do this soon.
>
> Here is what my test POC looked like for generating a simple shared
> library:
>
> #!/usr/bin/env python
>> # -*- coding: utf-8 -*-
>> import cmake
>> cmake.init("Ninja", "/media/dev/src/cmaketest",
>> "/media/dev/build/cmaketest")
>> myProject = cmake.Project("MyTestProject")
>> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ]
>> cmake.generate()
>
>
> Thanks a lot for your comments, I'm happy to see this was not just a dumb
> idea, and that others have thought about it.
>
> I'll update with the github as soon as I get it working.
>
> Best
>
>
> Le lun. 4 janv. 2016 à 01:16, Stephen Kelly  a écrit :
>
>> Charles Huet wrote:
>>
>> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure
>> > cannot be used from python (it check for the existence of a
>> CMakeLists.txt
>> > file, which does not exist in this scenario) and the cache variables it
>> > sets seem to be necessary.
>>
>> Because of the above, I worry that you are basing your work on an old
>> version of CMake. As of April 2015 cmState is used as the interface to the
>> cache.
>>
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13
>>
>> Also note that the C++ interfaces in CMake are not stable. In the last
>> year
>> they have been changed utterly and that will continue to happen without
>> notice. I'm sure you know this, but I thought I'd say it anyway.
>>
>> > I will try to make a layer of abstraction on top of the python bindings
>> > before publishing this work on github, in order to show the syntactic
>> > sugar python can provide, but I will publish this before if anybody is
>> > interested in working on this.
>>
>> I would be interested in seeing it.
>>
>> > Now, does anyone beside me think this is a good idea ?
>>
>> I did something similar some years ago with QML instead of python, so it
>> sounds interesting to me.
>>
>> In fact, one of the reasons for introducing cmState and doing all the
>> refactoring I did in cmake was to make it possible to 

Re: [cmake-developers] script mode current directory

2015-10-05 Thread Tamás Kenéz
file ${CMAKE_COMMAND} -P nosuchscriptfile.cmake)

+set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/P_working-dir-build)
+file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
+run_cmake_command(P_working-dir ${CMAKE_COMMAND}
-DEXPECTED_WORKING_DIR=${RunCMake_TEST_BINARY_DIR} -P
${RunCMake_SOURCE_DIR}/P_working-dir.cmake)
+unset(RunCMake_TEST_BINARY_DIR)
+
 run_cmake_command(build-no-dir
   ${CMAKE_COMMAND} --build)
 run_cmake_command(build-no-cache
-- 
2.2.1


On Fri, Oct 2, 2015 at 2:45 PM, Brad King <brad.k...@kitware.com> wrote:

> On 10/02/2015 08:00 AM, J Decker wrote:
> > On Fri, Oct 2, 2015 at 4:40 AM, Tamás Kenéz wrote:
> >> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
> >> variables are set to the current working directory.
> >
> > if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
> > something wrong :)   That implies that you're doing an in-source build
>
> Tamas is not doing a build at all but instead running
>
>  cmake -P myscript.cmake
>
> and checking the values of these variables.  Yes, the four variables
> are meant to be the current working directory in script mode.  This
> should be added to the documentation, but such a patch should also
> come with an update to the test suite, perhaps in RunCMake/CommandLine,
> that covers the behavior explicitly.
>
> -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
>
-- 

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] script mode current directory

2015-10-02 Thread Tamás Kenéz
In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
variables are set to the current working directory.

Is this something we can rely on and it could be added to the documentation?

Tamas
-- 

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 Find modules out of the CMake tree

2015-09-30 Thread Tamás Kenéz
> but I doubt the non-CMake ones generate SDL2Config.cmake files.

neither of them generates, not even the CMake one

On Wed, Sep 30, 2015 at 5:11 PM, Ben Boeckel 
wrote:

> On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote:
> > With regard to SDL2, the proper way to make it find-able with CMake is
> > for SDL2 to provide a CMake packaging files themselves as part of their
> > own distribution (since they build with CMake):
>
> Just to note, SDL2 also has build systems for ~every buildsystem out
> there (VS projects, Xcode projects, Android.mk, autotools, premake,
> etc.). I *think* those are for ease-of-embedding, but I doubt the
> non-CMake ones generate SDL2Config.cmake files.
>
> --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] Allow ALIAS of IMPORTED targets

2015-09-15 Thread Tamás Kenéz
Thank you, I was not aware of the EXPORT_NAME target property.
Tamas

On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly <steve...@gmail.com> wrote:

> Tamás Kenéz wrote:
>
> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
> can
> > be
> >> exported with export() and install(EXPORT)?
> >
> > Yes: couple of months ago I was adding install(EXPORT) to an existing
> > CMakeList. The name of the library target which I had to export was not
> > correct as export target name but I was not able change the library
> target
> > name because of backward compatibility. Being able to export an alias
> > would have helped.
>
> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
> Just too keep the branch and discussion as short as possible.
>
> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
> They are more than you need. You don't need the aliases anywhere except for
> exporting. So, we could design something which allows you to export
> aliases,
> but be completely separate from ALIAS targets.
>
> For example,
>
>  add_library(foo ${foo_SRCS})
>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>
>  ...
>
>  install(EXPORT ...)
>
> resulting in a generated file containing
>
>  add_library(foo IMPORTED)
>  ...
>
>  add_library(foo_old_name IMPORTED)
>  ...
>
> where each of the generated targets get the same target properties.
>
> Note that there is already an EXPORT_NAME target property
>
>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>
> but it is not a list, so the task would probably be to deprecate that one
> and add EXPORT_NAMES.
>
> I filed
>
>  http://public.kitware.com/Bug/view.php?id=15745
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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] Allow ALIAS of IMPORTED targets

2015-09-14 Thread Tamás Kenéz
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
be
> exported with export() and install(EXPORT)?

Yes: couple of months ago I was adding install(EXPORT) to an existing
CMakeList. The name of the library target which I had to export was not
correct as export target name but I was not able change the library target
name because of backward compatibility. Being able to export an alias would
have helped.

> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
> MyNS::MyNS::Core

I guess so, at least that's what I would expect. As far as I know the
install(EXPORT) blindly preprends the target name with the namespace string.

Tamas

On Mon, Sep 14, 2015 at 7:34 PM, Stephen Kelly  wrote:

> Michael Scott wrote:
>
> > Hi,
> >
> > I'm planning on having a look at the CMake issue "Allow ALIAS of
> > IMPORTED targets", 0015569. After reading the thread between yourself
> > and Marc, I wanted to ask a couple of things before I start going
> > further with it.
>
> Thanks for working on this.
>
> > The proposed change would be for the add_library and add_executable
> > commands only right?
>
> Yes, I guess so.
>
> > Having a quick look at the code for those two commands, they
> > specifically check for a combination of ALIAS and IMPORTED and don't
> > allow it. I'm guessing that the required changes to allow both
> > simultaneously wouldn't be to just remove this check, there would be
> > other areas to modify as well right?
>
> Perhaps. Finding that out is the real task :). I don't have all the answers
> to it. The specific disallowing of ALIAS and IMPORTED together by issuing
> an
> error was a way to defer finding those answers while not being required to
> maintain compatibility with a particular behavior. I didn't want finding
> those answers to delay getting the ALIAS feature in, because it was useful
> already as it was.
>
> Now, we have time to consider all of the implications of allowing this as
> part of the design.
>
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
> be
> exported with export() and install(EXPORT)?
>
> If we have
>
>  add_library(CoreStatic ${Core_SRCS})
>  add_library(MyNS::Core ALIAS CoreStatic)
>
> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
>
>  MyNS::MyNS::Core
>
> ?
>
> Or would the exporting code strip of everything before a '::' in the alias
> name?
>
> Or should exporting ALIAS targets still be disallowed?
>
> The two use cases described in
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
> seem like they would not benefit from exporting ALIAS targets.
>
> A reasonable way forward might be:
>
> * Keep the restriction that ALIAS targets may not be exported.
> * Remove the code disallowing ALIAS IMPORTED targets.
> * Remove the unit test proving it is not allowed
> * Add new unit tests that it basically works
> * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
> * (Anything else that comes up along the way)
>
> Thanks,
>
> Steve.
>
>
> --
>
> 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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

2015-07-17 Thread Tamás Kenéz
 What is your actual use case for expanding this info during the configuration
process?

We feed our static lib and the list of its dependencies to the `libtool` to
create an amalgamated, standalone static library.
This is an iOS-specific issue: we need this because iOS doesn't support
shared libraries and we want to provide our users a single static lib
instead of 20-30.

Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit the
current concepts. We will then use a local modified copy of it or try to
solve the issue by `install(CODE ..)` to postpone the amalgamation to
install time where the generator expressions can be resolved.

Thanks,
Tamas

(sorry for not replying-to-all in previous email)


On Fri, Jul 17, 2015 at 5:41 PM, Brad King brad.k...@kitware.com wrote:

 On 07/16/2015 11:29 AM, Tamás Kenéz wrote:
  Well, it seems that `BundleUtilities` can't expand a single static
 imported
  library target to the list of all dependent libraries (that's what I
 need)
  so I think `CMakeExpandImportedTargets` is still benefitial and could be
  benefitial to others, too.

 The BundleUtilities suggestion in the issue tracker page you linked
 was specific to the CPack use case discussed there.

  My patch enables `CMakeExpandImportedTargets` to use the
  `INTERFACE_LINK_LIBRARIES` property and also resolves the $CONFIG,
  $NOT and $0|1: generator expressions.

 This module should not be further maintained and should instead be
 deprecated:

 * Its original use case was to expand imported targets for calling
   try_compile and try_run.  Both now support imported targets
   natively in their LINK_LIBRARIES options so it is no longer
   needed (or used by CMake's own modules) for this purpose.

 * It is not possible to implement with generator expressions in
   general (see below).

  I found no elegant way to resolve all generator expressions
  (`file(GENERATE ...)` can't be used since it does not output the
  resolved content instantly).

 Generator expressions by definition cannot be evaluated until generate
 time because their evaluation can access information that is not
 available until then.  Even for imported targets with a given
 CONFIGURATION value we may not have all the information needed to
 expand INTERFACE_LINK_LIBRARIES.  For example, that property may
 contain expressions like $TARGET_PROPERTY:prop that refer to the
 target for which the link line is currently generating.

 What is your actual use case for expanding this info during the
 configuration process?

 -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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

2015-07-16 Thread Tamás Kenéz
I submitted a patch to update `CMakeExpandImportedTargets` with
`INTERFACE_LINK_LIBRARIES`.
Shortly after I read the discussion at http://www.cmake
.org/Bug/view.php?id=15299 which suggested `CMakeExpandImportedTargets` is
deprecated and one should use `BundleUtilities` instead.

Well, it seems that `BundleUtilities` can't expand a single static imported
library target to the list of all dependent libraries (that's what I need)
so I think `CMakeExpandImportedTargets` is still benefitial and could be
benefitial to others, too.

My patch enables `CMakeExpandImportedTargets` to use the
`INTERFACE_LINK_LIBRARIES`
property and also resolves the $CONFIG, $NOT and $0|1: generator
expressions. I found no elegant way to resolve all generator expressions
(`file(GENERATE ...)` can't be used since it does not output the resolved
content instantly).

Tamas

On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote:

 The CMakeExpandedImportedTargets module used only the deprecated
 IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
 dependencies.
 Since the current `install(EXPORT ...)` command generates target files
 that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
 working correctly with the imported libraries generated by `install(EXPORT
 ...)`.

 I considered this a bugfix so I based the commit onto the release branch.

 Please review and apply if it's ok.
 Tamas


 From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
 From: Tamas Kenez tamas.ke...@gmail.com
 Date: Wed, 15 Jul 2015 17:47:50 +0200
 Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES
 if
  non-empty

 The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
 overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

 Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
 usually contains config-related generator expressions which must
 be resolved according to the selected configuration.
 ---
  Modules/CMakeExpandImportedTargets.cmake | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

 diff --git a/Modules/CMakeExpandImportedTargets.cmake
 b/Modules/CMakeExpandImportedTargets.cmake
 index 8ac3364..b110e51 100644
 --- a/Modules/CMakeExpandImportedTargets.cmake
 +++ b/Modules/CMakeExpandImportedTargets.cmake
 @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
  list(GET _importedConfigs ${_configIndexToUse}
 _importedConfigToUse)

  get_target_property(_importedLocation ${_CURRENT_LIB}
 IMPORTED_LOCATION_${_importedConfigToUse})
 -get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 INTERFACE_LINK_LIBRARIES)
 +if(_linkInterfaceLibs)
 +   # resolve $CONFIG:... generator expressions
 +   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$CONFIG:[^]* 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $NOT:(0|1)
 +   string(REGEX REPLACE \\$NOT:0 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$NOT:1 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $(0|1):...
 +   # empty items will be ignored by `foreach` later
 +   string(REGEX REPLACE \\$0:[^]* 
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$1:([^]*) \\1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +else()
 +   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +endif()

  list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
  #message(STATUS Appending lib ${_CURRENT_LIB} as
 ${_importedLocation})
 --
 1.9.4.msysgit.2


-- 

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] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

2015-07-15 Thread Tamás Kenéz
I've just read the discussion at
http://www.cmake.org/Bug/view.php?id=15299 about
the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to
it.

I'm checking BundleUtilities as suggested there.

Tamas

On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote:

 The CMakeExpandedImportedTargets module used only the deprecated
 IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
 dependencies.
 Since the current `install(EXPORT ...)` command generates target files
 that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
 working correctly with the imported libraries generated by `install(EXPORT
 ...)`.

 I considered this a bugfix so I based the commit onto the release branch.

 Please review and apply if it's ok.
 Tamas


 From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
 From: Tamas Kenez tamas.ke...@gmail.com
 Date: Wed, 15 Jul 2015 17:47:50 +0200
 Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES
 if
  non-empty

 The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
 overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

 Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
 usually contains config-related generator expressions which must
 be resolved according to the selected configuration.
 ---
  Modules/CMakeExpandImportedTargets.cmake | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

 diff --git a/Modules/CMakeExpandImportedTargets.cmake
 b/Modules/CMakeExpandImportedTargets.cmake
 index 8ac3364..b110e51 100644
 --- a/Modules/CMakeExpandImportedTargets.cmake
 +++ b/Modules/CMakeExpandImportedTargets.cmake
 @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
  list(GET _importedConfigs ${_configIndexToUse}
 _importedConfigToUse)

  get_target_property(_importedLocation ${_CURRENT_LIB}
 IMPORTED_LOCATION_${_importedConfigToUse})
 -get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 INTERFACE_LINK_LIBRARIES)
 +if(_linkInterfaceLibs)
 +   # resolve $CONFIG:... generator expressions
 +   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$CONFIG:[^]* 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $NOT:(0|1)
 +   string(REGEX REPLACE \\$NOT:0 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$NOT:1 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $(0|1):...
 +   # empty items will be ignored by `foreach` later
 +   string(REGEX REPLACE \\$0:[^]* 
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$1:([^]*) \\1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +else()
 +   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +endif()

  list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
  #message(STATUS Appending lib ${_CURRENT_LIB} as
 ${_importedLocation})
 --
 1.9.4.msysgit.2


-- 

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] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

2015-07-15 Thread Tamás Kenéz
The CMakeExpandedImportedTargets module used only the deprecated
IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
dependencies.
Since the current `install(EXPORT ...)` command generates target files that
populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
working correctly with the imported libraries generated by `install(EXPORT
...)`.

I considered this a bugfix so I based the commit onto the release branch.

Please review and apply if it's ok.
Tamas


From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
From: Tamas Kenez tamas.ke...@gmail.com
Date: Wed, 15 Jul 2015 17:47:50 +0200
Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if
 non-empty

The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
usually contains config-related generator expressions which must
be resolved according to the selected configuration.
---
 Modules/CMakeExpandImportedTargets.cmake | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
index 8ac3364..b110e51 100644
--- a/Modules/CMakeExpandImportedTargets.cmake
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
 list(GET _importedConfigs ${_configIndexToUse}
_importedConfigToUse)

 get_target_property(_importedLocation ${_CURRENT_LIB}
IMPORTED_LOCATION_${_importedConfigToUse})
-get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
INTERFACE_LINK_LIBRARIES)
+if(_linkInterfaceLibs)
+   # resolve $CONFIG:... generator expressions
+   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$CONFIG:[^]* 0
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   # resolve $NOT:(0|1)
+   string(REGEX REPLACE \\$NOT:0 1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$NOT:1 0
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   # resolve $(0|1):...
+   # empty items will be ignored by `foreach` later
+   string(REGEX REPLACE \\$0:[^]* 
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$1:([^]*) \\1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+else()
+   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+endif()

 list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
 #message(STATUS Appending lib ${_CURRENT_LIB} as
${_importedLocation})
-- 
1.9.4.msysgit.2
-- 

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] OBJECT library on left-hand-side of target_link_libraries

2015-07-08 Thread Tamás Kenéz
The documentation states that OBJECT libraries may not be [...] used in the
right hand side of target_link_libraries().

However it turns out that they can't be used on the left hand side either:

add_library(objlib OBJECT ...)
target_link_libraries(objlib dep-of-objlib)

Result:

CMake Error at CMakeLists.txt:13 (target_link_libraries):
  Object library target objlib may not link to anything.

This makes it impossible to concisely specify if an OBJECT library has a
dependency which is an IMPORTED library.

Only the legacy way works:

add_library(objlib OBJECT ...)
target_include_directories(objlib ${ZLIB_INCLUDE_DIRS})
...
add_executable(maintarget $TARGET_OBJECTS:objlib)
target_link_libraries(maintarget ${ZLIB_LIBRARIES})

But it would be convenient if this would also work:

add_library(objlib OBJECT ...)
target_link_libraries(objlib ZLIB::ZLIB)


Question:

Is this restriction, that an OBJECT library can't be on the left hand side
of
target_link_libraries, is it a hard, final decision? Or is this issue
open for a possible improvement which would allow this and would forward
the link dependencies to the main target the OBJECT library is incorporated
into?

Tamas
-- 

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] Help: fix FindMatlab section headers

2015-06-29 Thread Tamás Kenéz
Hi,

FindMatlab used dash for its internal headers.
This commit replaces caret-headers with double-quote-headers and replaces
dash-headers with caret-headers.

On top of release.

Tamas


0001-Help-fix-FindMatlab-section-headers.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

[cmake-developers] find_package config mode search path rule #5 error prone

2015-05-06 Thread Tamás Kenéz
Hi,

The search path rule #5 reads:

 Search project build trees recently configured in a cmake-gui(1). This can be 
 skipped if
 NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is 
 building
 multiple dependent projects one after another. (This step is implemented only 
 on Windows.)

I think this rule, while having the best intentions, is error prone
(speaking from experience).
There are great and proper ways to use the products of a project in a
dependent project. Opening the project in cmake-gui to expose the
byproduct of a config-module configuration+installation process in the
binary dir, is not of them.

What do you think, would it be wise to disable this rule with a new
policy? Would anybody miss it?

Tamas
-- 

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 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

2015-04-17 Thread Tamás Kenéz
 Are you interested in working on a patch for this?

Yes, I'd give it a try. I signed up to Mantis, account: tamas.kenez so
you can assign it to me. I guess that's the next step.

Thanks,
Tamas

On Fri, Apr 17, 2015 at 2:01 PM, Brad King brad.k...@kitware.com wrote:
 On 04/16/2015 05:54 AM, Tamás Kenéz wrote:
 I think the main challenge will be how to format error messages when
 neither mode finds anything for a REQUIRED package.

 We can pretend they failed in the usual module;config order. So the
 wordings of the messages may remain as they are.

 The current message says:

   By not providing Findpkg.cmake in CMAKE_MODULE_PATH this project
   has asked CMake to find a package configuration file ...

 If someone sets CMAKE_FIND_PACKAGE_CONFIG_FIRST then that is what
 asked CMake to find a package configuration file even if the project
 does provide Findpkg.cmake in CMAKE_MODULE_PATH.  Therefore new
 wording will be needed in this case.  It should still depend on
 whether the find module was available.

 We should however think about what to do when
 CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled
 (and we're in CONFIG_FIRST mode). Should we check the missing
 find-module *after* we've found a config-module and print the warning?

 I think no, because the user has explicitly expressed the preference
 towards the CONFIG mode by specifying CONFIG_FIRST (either as a
 find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST).

 Agreed.  We can always add such a warning in the future.

 About the proposed change: The feature request proposes two ways to
 enable the CONFIG_FIRST mode: a new option for the find_package and a
 global variable (which I think should be called
 CMAKE_FIND_PACKAGE_CONFIG_FIRST).

 I think the find_package option is less important since the same
 effect can be achieved by creating a custom
 find_package_config_first() macro.

 If the functionality is implemented through either interface it will
 be easy to add the other, so I think they can just both be added
 together.

 Are you interested in working on a patch for this?

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

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] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

2015-04-16 Thread Tamás Kenéz
The https://public.kitware.com/Bug/view.php?id=15231 feature request
proposes a new feature to make find_package to attempt CONFIG mode
first.

On 10/31/2014 01:30 PM, Brad King wrote:

 I think the main challenge will be how to format error messages when
 neither mode finds anything for a REQUIRED package. It took years to
 get the current messages to a state that minimizes confusion among users
 that do not understand the two modes.

I think when neither mode finds anything it doesn't matter in which
order they failed.
We can pretend they failed in the usual module;config order. So the
wordings of the messages may remain as they are.

We should however think about what to do when
CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled
(and we're in CONFIG_FIRST mode). Should we check the missing
find-module *after* we've found a config-module and print the warning?

I think no, because the user has explicitly expressed the preference
towards the CONFIG mode by specifying CONFIG_FIRST (either as a
find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST).

About the proposed change: The feature request proposes two ways to
enable the CONFIG_FIRST mode: a new option for the find_package and a
global variable (which I think should be called
CMAKE_FIND_PACKAGE_CONFIG_FIRST).

I think the find_package option is less important since the same
effect can be achieved by creating a custom
find_package_config_first() macro.
To simulate the effect of the global variable is much more difficult
and heavy-weight.

Tamas
-- 

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