[cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

[Gilles Khouzam via cmake-developers]

This patch is to add the ability with Visual Studio generators to add 
references to SDKs. This is similar to the DESKTOP, IOT and MOBILE extensions 
for Windows 10, but makes the process more generic, using the Property 
VS_SDK_REFERENCES as a semi-colon separated list.

For example, adding a reference to the AdMediatorSDK would look something like 
this:

set_property(TARGET ${EXE_NAME} PROPERTY VS_SDK_REFERENCES 
"Microsoft.AdMediatorWindows81, Version=1.0")


0001-VS_SDK_REFERENCES.patch
Description: 0001-VS_SDK_REFERENCES.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Patch: Add ability to override the default Visual Studio tool

[Gilles Khouzam via cmake-developers]

This patch is to add the ability to override the default tool assigned by the 
Visual Studio generator based on the extension, by using a new source property 
VS_TOOL_OVERRIDE. This also allows for new tools to be defined without having 
to teach CMake how to handle them.

For example, this allows to have resource support (.resw) files and specifying 
that they are processed with the PRIResource tool.


0001-VS_TOOL_OVERRIDE.PATCH
Description: 0001-VS_TOOL_OVERRIDE.PATCH
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode: Infrastructure

[Brad King]

On 06/13/2016 08:00 PM, Tobias Hunger wrote:
> * There will always be 1 client talking to a server.
> * Client/Server communicate using JSON messages

Yes.  IIRC it is using stdin/stdout (I haven't checked the code),
so limiting to one client is implicit.

In this case, is it actually a daemon?  It is not expected to outlive
the client that started it.  Perhaps we should consider a different name.

One possible problem with using stdin/stdout is that when CMake runs the
configuration the project code can do things like execute_process that
may share the stdout with the child process.  That may allow the child
process to print content formatted to look like the protocol and trick
the client.  Ideally all output handling would avoid printing things to
stdout in server/daemon mode, but that may take some effort to achieve.

> What do you think? Does this make sense?

It sounds fine to me.  I'll state the caveat that I've had little experience
in maintaining versioned protocols like this though.  Hopefully others can
review this too.

On 06/14/2016 04:30 AM, Tobias Hunger wrote:
> I think it would make perfect sense to ship the first cmake version with
> included daemon-mode with a big, fat warning that the interfaces are not
> finalized yet and will change in incompatible ways during the first release
> cycle (or maybe two:-).

Yes.  Should we make the option to activate it different, and include
"experimental" in its name?  I think the idea is that no clients should
be released that depend on the experimental behavior in CMake.

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

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/10/2016 12:31 PM, Tobias Hunger wrote:
> I did try to do the changes you requested. The branch is here:
> https://github.com/hunger/CMake/commits/compileflags

Thanks.  I did some refactoring to help address the path conversion
problem:

 Refactor Makefile/Ninja tool working directory storage
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0392f72b

Then I applied the patches with some revisions:

 cmGeneratorTarget: Adopt Fortran module directory generation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d

 cmLocalGenerator: Add method to get Fortran-specific compiler flags
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794

 cmLocalGenerator: Adopt target compile flag generation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8

 cmExtraSublimeTextGenerator: Use GetTargetCompileFlags
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb

These have been merged to `next` for testing.

> Next patch moves the AddFortranFlags code. This will need some careful
> review, as it removes a path conversion that were present in the
> original code (in two places). I could just not figure out how
> to convert in the new place.

I replaced that commit with a different one that preserves the path
conversion.  The implementation needs to be in cmLocalCommonGenerator
in order to have access to the needed information to do the conversion.
I used virtual dispatch to achieve this.  On other generators we do
not need these flags anyway.

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

Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

[Brad King]

On 06/17/2016 01:33 PM, Christian Schmidbauer wrote:
>> CMake sets the lib32/lib64 ones in its own
>> platform modules for the relevant platforms so user code never
>> needs to do it.  Where in user code would it be done?
> 
> In my setup, I would create a custom my-config.cmake file

And that is included from CMakeLists.txt files?

> SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search path" 
> FORCE)

I think you meant to use set_property here.  It is not a cache entry.
However, see below.

> This way I can overwrite cmake's default lib32/lib64 search folders.
> Why do you ask? Do you have a specific opinion about this?

If the goal is to be able to override it for a local build then
we shouldn't have to modify the project CMake code.  Setting the
global property requires editing code.  The existing properties
FIND_LIBRARY_USE_LIB{32,64}_PATHS make sense because they are
configured by CMake as properties of the current system.

Instead we could activate this behavior through a variable that
could then be added to the cache on the command line via -D.
That would allow local builds to configure any project to search
this way.  For example:

  cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32

-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] Allow LIB_SUFFIX be used as find path

[Christian Schmidbauer]

On Fri, Jun 17, 2016 at 7:13 PM, Brad King  wrote:
> On 06/17/2016 12:53 PM, Christian Schmidbauer wrote:
>>> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation,
>>> or whatever it becomes after the discussion below.
>>>
>> Where do you want me to document it?
>
> In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was
> added.  Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and
> associated links to it.
>
Ok, I will add those and re-send the patch.

>>> Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties
>>> can be set by the platform information modules in CMake itself
>>> on platforms that need the behavior.  In what context might the
>>> FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice?
>>>
>> In custom environments, where neither lib, lib32 or lib64 would serve
>> the purpose but some custom library folder.
>
> Actually I was asking in what source code context the actual
>
>  set(LIB_SUFFIX ...)
>  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...)
>
> lines would appear.  CMake sets the lib32/lib64 ones in its own
> platform modules for the relevant platforms so user code never
> needs to do it.  Where in user code would it be done?
>
> Thanks,
> -Brad
>

In my setup, I would create a custom my-config.cmake file like which I
can include in each cmake build with the following content:

SET (LIB_SUFFIX x32 CACHE STRING "library path suffix" FORCE)
SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32
search path" FORCE)
SET (CMAKE_INSTALL_LIBDIR libx32 CACHE PATH "Output directory for libraries")

This way I can overwrite cmake's default lib32/lib64 search folders.
Why do you ask? Do you have a specific opinion about this?

Best regards,
Chris
-- 

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] FindFreetype patch for Windows debug lib naming

[Stuart Mentzer]

On 6/17/2016 1:12 PM, Brad King wrote:

On 06/17/2016 01:02 PM, Stuart Mentzer wrote:

Thanks but a line was lost in translation at the bottom:

mark_as_advanced(
   *FREETYPE_LIBRARY*
   FREETYPE_INCLUDE_DIR_freetype2
   FREETYPE_INCLUDE_DIR_ft2build
)

SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables
but I assume we still need the base variable handled in FindFreetype.

I dropped it intentionally.  We no longer add FREETYPE_LIBRARY to
the cache, so we are not responsible for marking it as advanced.
We only use the value if it was set by someone else.

-Brad

Ah, OK. This doesn't match the usage in FindZlib that I was using as a guide:

mark_as_advanced(ZLIB_LIBRARY ZLIB_INCLUDE_DIR)

Stuart
--

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] Allow LIB_SUFFIX be used as find path

[Brad King]

On 06/17/2016 12:53 PM, Christian Schmidbauer wrote:
>> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation,
>> or whatever it becomes after the discussion below.
>>
> Where do you want me to document it?

In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was
added.  Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and
associated links to it.

>> Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties
>> can be set by the platform information modules in CMake itself
>> on platforms that need the behavior.  In what context might the
>> FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice?
>>
> In custom environments, where neither lib, lib32 or lib64 would serve
> the purpose but some custom library folder.

Actually I was asking in what source code context the actual

 set(LIB_SUFFIX ...)
 set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...)

lines would appear.  CMake sets the lib32/lib64 ones in its own
platform modules for the relevant platforms so user code never
needs to do it.  Where in user code would it be done?

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

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

[Brad King]

On 06/17/2016 01:02 PM, Stuart Mentzer wrote:
> Thanks but a line was lost in translation at the bottom:
> 
> mark_as_advanced(
>   *FREETYPE_LIBRARY*
>   FREETYPE_INCLUDE_DIR_freetype2
>   FREETYPE_INCLUDE_DIR_ft2build
> )
> 
> SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables
> but I assume we still need the base variable handled in FindFreetype.

I dropped it intentionally.  We no longer add FREETYPE_LIBRARY to
the cache, so we are not responsible for marking it as advanced.
We only use the value if it was set by someone else.

-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] FindFreetype patch for Windows debug lib naming

[Rolf Eike Beer]

Am Freitag, 17. Juni 2016, 13:02:30 schrieb Stuart Mentzer:
> On 6/17/2016 11:54 AM, Brad King wrote:
> On 06/12/2016 01:52 PM, Stuart Mentzer wrote:
> Looking at FindZlib.cmake I think the attached should be OK
> Thanks.  I've applied that as a patch here:
> 
>  FindFreetype: Find release and debug libraries separately
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6
> 
> -Brad
> Thanks but a line was lost in translation at the bottom:
> 
> mark_as_advanced(
>   FREETYPE_LIBRARY
>   FREETYPE_INCLUDE_DIR_freetype2
>   FREETYPE_INCLUDE_DIR_ft2build
> )
> 
> SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables but I
> assume we still need the base variable handled in FindFreetype.
> 
> With that fix, if Eike is OK with this then it is done.

No, this is actually correct. The things marked as advanced are cache 
variables. FREETYPE_LIBRARY is computed dynamically. The "advanced" thing is 
to hide these in the default view of cmake-gui.

If Brad says the change of what is cached is ok I'm entirely fine with it.

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] FindFreetype patch for Windows debug lib naming

[Stuart Mentzer]

  
  
On 6/17/2016 11:54 AM, Brad King wrote:

  On 06/12/2016 01:52 PM, Stuart Mentzer wrote:

  
Looking at FindZlib.cmake I think the attached should be OK

  
  
Thanks.  I've applied that as a patch here:

 FindFreetype: Find release and debug libraries separately
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6

-Brad


Thanks but a line was lost in translation at the bottom:

mark_as_advanced(
  FREETYPE_LIBRARY
  FREETYPE_INCLUDE_DIR_freetype2
  FREETYPE_INCLUDE_DIR_ft2build
)

SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables
but I assume we still need the base variable handled in
FindFreetype.

With that fix, if Eike is OK with this then it is done.

Thanks,
Stuart
  

-- 

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] Allow LIB_SUFFIX be used as find path

[Christian Schmidbauer]

On Mon, Jun 13, 2016 at 5:22 PM, Brad King  wrote:
> Hi Christian,
>
> Thanks for working on this.
>
> On 06/12/2016 05:59 AM, Christian Schmidbauer wrote:
>> A similar idea has already been suggested in #10287
>
> Yes.
>
>> and is required for bug #15594.
>
> That issue appears unrelated.  Did you typo the number?
>
Indeed, I meant bug #15994.

>>  Help/command/find_library.rst  |  5 
>>  Help/manual/cmake-properties.7.rst
>
> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation,
> or whatever it becomes after the discussion below.
>
Where do you want me to document it?

>> +If the :prop_gbl:`FIND_LIBRARY_USE_CUSTOM_SUFFIX` global property is set
>> +all search paths will be tested as normal, with `LIB_SUFFIX` appended, and
>> +with all matches of ``lib/`` replaced with `lib${LIB_SUFFIX}/`.  This 
>> property
>> +overrides both `FIND_LIBRARY_USE_LIB32_PATHS` and 
>> `FIND_LIBRARY_USE_LIB64_PATHS`.
> [snip]
>> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX TRUE)
>> +set(LIB_SUFFIX "XYZ")
>
> Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties
> can be set by the platform information modules in CMake itself
> on platforms that need the behavior.  In what context might the
> FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice?
>
> Thanks,
> -Brad
>
In custom environments, where neither lib, lib32 or lib64 would serve
the purpose but some custom library folder. I have a multilib system
with an additional "libx32" next to lib/lib32 and lib64. Currently,
you have to trick cmake in order to for libraries to be found. You
could go ahead and add a similar patch like the lib32 one, but I think
it's a better approach to let the user decide in such scenarios where
he wants cmake to look.

Best regards,
Chris
-- 

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] FindFreetype patch for Windows debug lib naming

[Brad King]

On 06/12/2016 01:52 PM, Stuart Mentzer wrote:
> Looking at FindZlib.cmake I think the attached should be OK

Thanks.  I've applied that as a patch here:

 FindFreetype: Find release and debug libraries separately
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6

-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] codeblocks generator: Fix include directories being in unexpected order

[Brad King]

On 06/17/2016 03:31 AM, Tobias Hunger wrote:
> Could this please go into 3.6?
> 
> This is the root cause of quite a few bug reports hitting Qt Creator bug 
> tracker
> right now, so I would love to see a fix out in the wild ASAP.

Normally I don't make non-regression/doc fixes after the first RC
but this change seems pretty isolated.  I've rebased the commit
back before the release branch:

 cmExtraCodeBlocksGenerator: Do not shuffle include directories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76b462ea

I've queued this for merge to `release` for 3.6.

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

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Ben Boeckel]

On Fri, Jun 17, 2016 at 15:40:45 +0200, Nils Gladitz wrote:
> I have not been involved in that development.
>  From what I can tell this is Eike's work.

Ack, sorry. Should have double checked.

--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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Brad King]

On 06/17/2016 09:40 AM, Nils Gladitz wrote:
> On 06/17/2016 03:36 PM, Ben Boeckel wrote:
>> Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
>> for that. However, it is hidden behind the check that pkg_check_modules
>> uses to see if it already ran:
> 
>  From what I can tell this is Eike's work.

Yes.

On 06/17/2016 09:36 AM, Ben Boeckel wrote:
> Brad, this is in the rc releases; what should be done? Block the
> release, undocument the feature, or wait for a patch?

Since it is a bug in a new feature a fix qualifies for inclusion
in the release.  If Eike can solve it soon (which is likely) then
I'll include the fix.  Otherwise I'd revert the feature.

-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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Rolf Eike Beer]

Am 2016-06-17 15:36, schrieb Ben Boeckel:

Hi,

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:

if (NOT DEFINED __pkg_config_checked_${_prefix} OR
__pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR
NOT ${_prefix}_FOUND)

which means that on the second configure, the target is not created
causing build faiures. Could you please look at reordering the logic so
that the imported target is always created (if requested)? Thanks.

Brad, this is in the rc releases; what should be done? Block the
release, undocument the feature, or wait for a patch?


I also have another todo for FindFreetype open which I must handle. I'll 
do both over the weekend.


Greetings,

Eike
--

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] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Nils Gladitz]

On 06/17/2016 03:36 PM, Ben Boeckel wrote:

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:


I have not been involved in that development.
From what I can tell this is Eike's work.

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

[cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Ben Boeckel]

Hi,

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:

if (NOT DEFINED __pkg_config_checked_${_prefix} OR
__pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR
NOT ${_prefix}_FOUND)

which means that on the second configure, the target is not created
causing build faiures. Could you please look at reordering the logic so
that the imported target is always created (if requested)? Thanks.

Brad, this is in the rc releases; what should be done? Block the
release, undocument the feature, or wait for a patch?

--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] Toward a more deterministic ninja generator

[Nicolas Desprès]

On Thu, Jun 16, 2016 at 7:14 PM, Brad King  wrote:

> On 06/14/2016 11:18 AM, Nicolas Desprès wrote:
> > It makes the ninja generator more deterministic by sorting the
> > build edge's inputs/outputs. It does not introduce any
> > regression on my macbookpro.
> >
> > This could help to fix issue #15968.
>
> What examples of non-determinism have you observed after the changes
> already made for that issue?
>

The LINK_LIBRARIES list has not the same order for an executable target.  I
have that after the 79th generation using cmake 3.5.2. With cmake master
(d4283ca18b7) I did not reproduce it after 100 tries.


> >  + // We assume that commands using $in and $out varialbes do not care
> >  + // about the order of their inputs/outputs files, but commands that do
> >  + // not use them do care (like custom commands for instance).
>
> I'd prefer not to make this assumption.  CMake should order the
> inputs and outputs in a deterministic way before getting to the
> code in question.  If that is not happening then there may be
> a deeper problem.  Sorting this late is fixing the symptom.
>
>
Yes you are right.

I did not took enough time to read the issue history and I did not test
with master.

Sorry for the noise.

-- 
Nicolas Desprès
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

On Do, 2016-06-16 at 13:14 -0400, Brad King wrote:
> On 06/14/2016 11:52 AM, Tobias Hunger wrote:
> > https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc2866
> > 1e3
> > 
> > Is the same thing updated based on suggestions from Stephen.
> 
> Thanks, applied:
> 
>  cmExtraCodeBlocksGenerator: Do not shuffle include directories
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f190b069

Could this please go into 3.6?

This is the root cause of quite a few bug reports hitting Qt Creator bug tracker
right now, so I would love to see a fix out in the wild ASAP.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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