[cmake-developers] [CMake 0016049]: Resources generated with autorcc are always rebuilt using ninja

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16049 
== 
Reported By:Vidar Meland Ødegård
Assigned To:
== 
Project:CMake
Issue ID:   16049
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   high
Status: new
== 
Date Submitted: 2016-04-05 14:49 EDT
Last Modified:  2016-04-05 14:49 EDT
== 
Summary:Resources generated with autorcc are always rebuilt
using ninja
Description: 
By using ninja and autorcc the resources are always rebuilt on CMake >= 3.5.
CMake 3.4.3 does not have this issue.

Steps to Reproduce: 
cmake  -GNinja
ninja -v
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-05 14:49 Vidar Meland ØdegårdNew Issue
   
2016-04-05 14:49 Vidar Meland ØdegårdFile Added: bug.tar.gz   
   
==

-- 

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 API for warnings

[Ruslan Baratov via cmake-developers]

On 05-Apr-16 21:03, Brad King wrote:

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:

What about 3 properties containing list of 's (groups
unexpanded):

* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

We would need to define behavior when a warning appears in more than
one list.


Report an error in case of any type of conflicts. It may happens not 
only when same type appears in both DISABLE and ENABLE but for example 
when warning already defined by some group. E.g. "EVERYTHING;undef" is 
the same as "EVERYTHING". If user okay with having intersections (for 
any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may 
control this.



   Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.


You mean this:

compatibility-c++98=off
inline=off
special-members=off
catch-semantic-changed=off
covered-switch-default=off
inherits-via-dominance=off
name-length-exceeded=off
padded=off
this-used-in-init=off
EVERYTHING=on
EVERYTHING=error

versus this one:

DISABLE
  compatibility-c++98
  inline
  special-members
  catch-semantic-changed
  covered-switch-default
  inherits-via-dominance
  name-length-exceeded
  padded
  this-used-in-init
ENABLE
  EVERYTHING
TREAT_AS_ERROR
  EVERYTHING

?

Second variant looks clearer for me.



The name "ALL" may not be representative.  Even -Wall does not really enable
all possible warnings on some compilers.  I'd like to find another name that
captures the idea of enabling most warnings.  Or we could try to subsume it
into an interface for the warning level, with -Wall considered "high".


Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?




I'm not sure about mixing more languages. I think it will be similar to
COMPILE_OPTIONS (?), see no language specification in
`add_compile_options` command.

Right.  We do have the COMPILE_LANGUAGE genex for some limited use cases.
Its documentation even includes a COMPILE_OPTIONS example.  However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.


Since /Wall can be set by 'target_compile_options' then abstracting it 
by `target_compile_warnings(... ENABLE ALL)` should not be a problem I 
think.




Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.


See no point of this one. So say we have switch-enum warning which is 
only for C++, why do we need cxx-switch-enum? There is no c-switch-enum 
or any other *-switch-enum. If we are talking about 'undef' why do we 
need c-undef and cxx-undef? It mean the same and I think will be set or 
unset simultaneously.


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

Re: [cmake-developers] for C# language support

[Brad King]

On 04/04/2016 04:08 PM, Adam Treat via cmake-developers wrote:
> I have been working on improving the cmake language module for C# found here:

Thanks for working on this.  I'm adding Michael Stuermer to Cc who has
been working on support in the VS IDE generators:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15753/focus=16064

> One thing that has me a bit flummoxed is how to implement the following:
> 
> CMAKE_CSharp_CREATE_SHARED_LIBRARY
> CMAKE_CSharp_CREATE_SHARED_MODULE
> CMAKE_CSharp_CREATE_STATIC_LIBRARY
> 
> in CMakeCSharpInformation.cmake.  In C# libraries need to have all symbols 
> resolved
> at creation time just like executables and this means I need access to the 
> LINK_LIBRARIES
> property to correctly implement the above.  However, it seems this property 
> is empty
> for the above.

It is expected to be available for at least the shared/module link rules.
See cmMakefileTargetGenerator::CreateLinkLibs's implementation and its
call sites.  Also see cmLocalGenerator::ExpandRuleVariable for where
the placeholders like  get expanded.

-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 v2] language detection in FindBLAS and FindLAPACK (#0016039)

[Brad King]

On 04/03/2016 05:21 PM, melven.roehrig-zoell...@dlr.de wrote:
> Updated patch for a problem with find_package(BLAS/LAPACK)
> on Windows for pure Fortran projects.
> Now simply uses CMAKE__COMPILER_LOADED...

Thanks!  Applied:

 Find{BLAS,LAPACK}: Fix when used in pure Fortran projects (#16039)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1694112d

-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] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64

[Brad King]

On 04/05/2016 04:48 AM, melven.roehrig-zoell...@dlr.de wrote:
> Requested changes from Ben Boeckel,
> also adjusted the similar if("${...}" MATCHES ...) statements in the section 
> above.

Thanks.  Applied:

 CMakeDetermineFortranCompiler: Modernize conventions
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66fa6143

 Fortran: Fix platform id detection on mingw-w64
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c4f100a

-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 API for warnings

[Brad King]

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
> What about 3 properties containing list of 's (groups 
> unexpanded):
> 
> * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
> * COMPILE_WARNINGS_ENABLE # e.g. "ALL"
> * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

We would need to define behavior when a warning appears in more than
one list.  Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.

The name "ALL" may not be representative.  Even -Wall does not really enable
all possible warnings on some compilers.  I'd like to find another name that
captures the idea of enabling most warnings.  Or we could try to subsume it
into an interface for the warning level, with -Wall considered "high".

> I'm not sure about mixing more languages. I think it will be similar to 
> COMPILE_OPTIONS (?), see no language specification in 
> `add_compile_options` command.

Right.  We do have the COMPILE_LANGUAGE genex for some limited use cases.
Its documentation even includes a COMPILE_OPTIONS example.  However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.

Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.

-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] ninja/make compilation response file

[Dmitry Ivanov]

>Teaching the Ninja generator about response files for object file compilation 
>would be the way to go (and support for RC as well would be good since the 
>logic is likely the same).

I will time box it and see if I can do it in few days, if not we need to figure 
out if it can be done like a sponsored feature or something.
Actually same story with make file generators, doesn't look like they support 
response files for obj either.

>There was work to reduce the size of the generated build.ninja file.
>More work could be done, but the projects I was looking at would only get 
>marginal improvements from other techniques (though other projects with 
>different flag quantities might >show other things to improve). What version 
>of CMake are you using?

3.5.1 atm, 84 mb takes around 3-4 seconds for ninja to parse on my machine, 
which makes ninja slightly useless an fast incremental builds tool, which is a 
shame.

--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] ninja/make compilation response file

[Dmitry Ivanov]

Just checked the size that we are getting, it's 20 Mb for all Makefile and 
*.make combined, and 84 mb build.ninja

From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Monday, April 4, 2016 18:57
To: Dmitry Ivanov ; cmake-developers@cmake.org
Subject: Re: [cmake-developers] ninja/make compilation response file

On 04.04.2016 18:38, Nils Gladitz wrote:
On 04.04.2016 17:59, Dmitry Ivanov wrote:

PS. Can we do something about bloated cmake ninja generator ? in our case cmake 
generates 1.8 Mb Makefile and 84 Mb build.ninja, though ninja is still faster 
than make even in this case.

Curious. Did you count the accumulative size of all Makefile and Makefile2 
files (also in sub-directories)?
For a project of mine the ninja files are only half in size of what is 
generated for the Makefile generator (CMake 3.5.1).

Oh and the Makefile generator also uses build.make files which actually seem to 
be where most of the size goes.

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] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64

[Melven.Roehrig-Zoellner]

Requested changes from Ben Boeckel,
also adjusted the similar if("${...}" MATCHES ...) statements in the section 
above.

Regards

Melven
--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany

Melven Röhrig-Zöllner 
Telephone +492203 / 601 - 2574
www.DLR.de







0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch
Description: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.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