Re: [cmake-developers] Problems with icons for Windows Store 10.0

[Roman Wüger]

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would 
nevertheless very helpful to customize such things via variables and let CMake 
fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam :
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary 
> files into the project when they aren't specified. This includes the manifest 
> and the icons. Can you add your app manifest to the project (look at 
> Tests\VSWinStorePhone if you want an example) and the icons should not be 
> overridden then.
> 
> Thanks
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com] 
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman Wüger ; Gilles Khouzam 
> 
> Cc: CMake Developer MailingList ; CMake 
> MailingList 
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0
> 
>> On 10/05/2016 02:56 PM, Roman Wüger wrote:
>> I tried the following to copy the required app icons to the required 
>> destination:
>> 
>> configure_file(Logo.png 
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to 
> prevent that.  We'll need to have some configuration of where it gets those 
> files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing 
>> this?
> 
> Gilles?
> 
> -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] Generator options per-directory v. global

[Stephen Kelly]

Craig Scott wrote:

> I'm coming in half way to this discussion, so apologies if my comments
> interspersed below are not so well related to the core topic of
> discussion.

Hi Craig,

Thanks for your input.

> Consider the following example which perhaps better shows that this
> problem may not be as uncommon as first thought:
> 
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption")
> add_library(foo ...)
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse")
> 
> I think most developers probably expect foo to not have the -somethingElse
> option when it is compiled, but I believe it would have it. 

The difference occurs depending on when the value is read. See my 
CMAKE_CXX_STANDARD example below.

> If I understand things correctly, directory *properties* don't typically
> have this unexpected behaviour as their value at the time of defining the
> targets is used, not at the end of that directory's processing. 

It all depends on when the value is read. Something that is read at 
configure-time appears to have immediate effect, regardless of whether it is 
a 'directory property' or a set() 'definition'. 

When something that is read at generate-time (such as CMAKE_CXX_FLAGS) it 
takes on the value at the end of the directory.

You might be referring to things like this, which are still 'definitions' 
not 'directory properties':

 set(CMAKE_CXX_STANDARD 11)

 # Reads CMAKE_CXX_STANDARD 'now' at configure time
 add_executable(foo ...)

 set(CMAKE_CXX_STANDARD 14)

 # Reads CMAKE_CXX_STANDARD 'now' again!
 add_executable(bar ...)


The important distinction is where in the CMake C++ code the 
cmMakefile::GetDefinition call occurs - generate-time code or configure-time 
code.

This is a sideline just for your information. What this thread is really 
about is whether things should be read 'only once' or 'once per directory', 
and whether the CMake C++ code chooses one or the other deliberately or 
accidentally, and what impact that has on maintainability and refactoring.

> this behaviour of using the
> variable's value at the end of the directory processing is likely a
> surprise to many and probably already causes some head-scratching until
> devs figure it out. Is the problem being discussed here relating to
> CMAKE_CODELITE_USE_TARGETS
> much different?

It seems like a related example to me. The CMAKE_CODELITE_USE_TARGETS 
feature is trying to be related to a project() command, but it is read at 
the end of the directory. Usually, I would think that is not a problem the 
way most people write project() commands and set these kinds of settings.

However, in the general sense of how 'global' settings should work, I think 
things could be better.

>> Those are not problems users or contributors adding features encounter,
>> so that might affect a perception of 'big'ness. These problems only
>> bubble up during refactoring or under longer-term maintenance when the
>> true semantics of the code become known.
>>
> 
> Perhaps a bit more common than that, as the above example suggests.

Yes, those kinds of examples are the things that I would expect to arise 
during maintenance, perhaps several releases after a feature hits master.

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

Re: [cmake-developers] Generator options per-directory v. global

[Craig Scott]

I'm coming in half way to this discussion, so apologies if my comments
interspersed below are not so well related to the core topic of discussion.

On Thu, Oct 6, 2016 at 9:38 AM, Stephen Kelly  wrote:

> Brad King wrote:
>
> > The scoping doesn't
> > match the generator semantics exactly, but it is easy to use and
> > hasn't been a big problem.
>
> My mail is suggesting that it is a problem and is undesirable to maintain.
>
> Big is subjective, and there are not many complaints, because generally
> people don't try to set things like this per-directory (and if they did it
> would probably mostly do what they expect).
>
> The problems are
>
> 1) It is a behavior which is often not intended by the programmer.
> 2) It makes refactoring harder if such unintended behavior must be
> preserved.
> 3) It is unintuitive, because code such as
>
>  set(FOO ON)
>  project(p)
>  add_library(bar ...)
>  set(FOO OFF)
>
> looks like FOO is ON when defining the project and the target, but in
> reality it is only the value at the end of the directory that is consumed.
>

Consider the following example which perhaps better shows that this problem
may not be as uncommon as first thought:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption")
add_library(foo ...)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse")

I think most developers probably expect foo to not have the -somethingElse
option when it is compiled, but I believe it would have it. Given that it
is not unusual (but not necessarily wise) for projects to fiddle with
variables like CMAKE_CXX_FLAGS in subdirectories which could be brought in
via include() rather than add_subdirectory(), this behaviour of using the
variable's value at the end of the directory processing is likely a
surprise to many and probably already causes some head-scratching until
devs figure it out. Is the problem being discussed here relating to
CMAKE_CODELITE_USE_TARGETS
much different?

If I understand things correctly, directory *properties* don't typically
have this unexpected behaviour as their value at the time of defining the
targets is used, not at the end of that directory's processing. They serve
as defaults for target-specific properties at the point of the target being
defined. Not sure if that helps with the original topic of discussion here
though.



>
> Those are not problems users or contributors adding features encounter, so
> that might affect a perception of 'big'ness. These problems only bubble up
> during refactoring or under longer-term maintenance when the true semantics
> of the code become known.
>

Perhaps a bit more common than that, as the above example suggests.


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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch: Don't emit warning when config file not found

[Christoph Grüninger]

Hi Brad,
I am sorry, but I have to take up this subject again.

I want to include Vc (sometimes called Vc-Devel) as an optional
dependency. Vc provides a ConfigVc.cmake.

1. When I use "find_package(Vc)", many users get warnings that neither
FindVc.cmake nor VcConfig.cmake is found. The warning looks scary and
even distracts myself when I am scanning for relevant warning. It is an
optional dependency, so a single line "Could NOT find Vc (FindVc.cmake
or VcConfig.cmake not found)" would be enough.

2. When I use "find_package(Vc QUIET)", Vc does not show up in the
feature summary.

How can I achieve both without patching CMake?

Bye
Christoph

Am 10.08.2016 um 15:17 schrieb Brad King:
> On 08/09/2016 04:35 PM, Christoph Grüninger wrote:
>> I am annoyed by the lengthy and disturbing warning CMake emits when a
>> package is not found because neither a Find*.cmake file is found nor a
>> *config.cmake file. I always try to have zero warnings, but missing
>> dependencies is common. Emitting a warning is too much and too noisy in
>> my opinion.
>>
>> Please find attached patch, which reduces the warning to a single line
>> with the status that the package was not found.
> 
> We went through many iterations on the wording of that message in
> response to user feedback before settling on what is currently there.
> When someone wants a package to be found they need a good explanation
> when it is not and hints about how to resolve the problem.
> 
> If a dependency is optional and it is not a problem to be missing
> then the project can use the find_package QUIET option and then
> optionally add its own message() about the missing package.
> 
> -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] Problems with icons for Windows Store 10.0

[Brad King]

On 10/05/2016 02:56 PM, Roman Wüger wrote:
> I tried the following to copy the required app icons to the required 
> destination:
> 
> configure_file(Logo.png 
> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

That's a CMake-private directory whose location is an implementation detail.
Some other interface for configuring this behavior will be needed.

> The CMake process itself overrides those files at the end with the files from 
> the
> CMake's Template directory, which are empty.

>From the current implementation it doesn't look like there is anyway to prevent
that.  We'll need to have some configuration of where it gets those files.

> So, how could I use my icon files and/or what is the preferred way of doing 
> this?

Gilles?

-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] Problems with icons for Windows Store 10.0

[Roman Wüger]

Hello,

I tried the following to copy the required app icons to the required 
destination:

configure_file(Logo.png 
${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)

The CMake process itself overrides those files at the end with the files from 
the CMake's Template directory, which are empty.

So, how could I use my icon files and/or what is the preferred way of doing 
this?

Thanks in advance

Best Regards
Roman
-- 

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] Generator options per-directory v. global (was: CMake 3.7.0-rc1 now ready for testing!)

[Brad King]

On 10/04/2016 05:46 PM, Stephen Kelly wrote:
> This causes problems because now the code has to read the value for each 
> directory and can't assume that the value is always the same as the value 
> from the top-level CMakeLists file.

Many of these are honored only in the top-level directory anyway.
Such cases could have documentation updated.

Some of them may be per-`project()`.

> Is the answer 'Use global properties or a cache variable instead'?

The options need to be something easy for the project to set itself
or for a user to set.  A cache entry can work for that, but we don't
really often read cache entries directly and instead read variables
that fall back to cache entries if not defined.  The scoping doesn't
match the generator semantics exactly, but it is easy to use and
hasn't been a big 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] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Nils Gladitz]

On 04.10.2016 11:20, Tobias Hunger wrote:

On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote:

The list we need would thus be built up to contain all COMMAND
arguments to add_test that are also build targets in CMake.

The list would also need to include targets mentioned in generator
expressions such as `$`.  This will almost certainly
be better done as a CMake feature implemented in C++.  This was actually
an early design philosophy: do the hard stuff in C++ so that complex
logic is not needed in CMake-language code.

Access to the list of defined tests would be nice to have in the server-mode,
too:-)

If some work is done in that direction, please keep server-mode in mind when
designing the APIs. I would love to reuse them to expose that information to
clients.


This might be rare but the tests that cmake knows about might differ 
from the tests that ctest knows about given that tests can be 
dynamically defined through TEST_INCLUDE_FILE[1].


I've never used it that way but I was considering e.g. querying test 
binaries (produced at build time) for the tests they define and making 
those available dynamically when ctest processes CTestTestfile.cmake. 
This is in contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which 
tries to accomplish the same thing at configuration time by parsing test 
sources instead.


[1] https://cmake.org/cmake/help/v3.6/prop_dir/TEST_INCLUDE_FILE.html

Nils
--

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] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing!

[Raffi Enficiaud]

Le 04/10/16 à 22:32, Robert Maynard a écrit :

I am proud to announce the first CMake 3.7 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.7

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.7/release/3.7.html

[snip]


Modules
---
[snip]



* The "FindMatlab" module learned to find a SIMULINK component.


Hi there,

Please add the following to the changelog of the FindMatlab module:

The FindMatlab module learned to find the SIMULINK and MAT components. 
The matlab_add_mex command can now add executable and module mex files, 
and matlab_add_unit_test can now run inline matlab test code.


Thanks!
Raffi


--

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