Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

2016-06-08 Thread Michael Jäntsch 
Hi,

the code looks right to me. Thanks a lot for fixing that so quickly.

Brad is also right about the first byte. The command has the argument
already attached.

Michael

On 06/08/2016 06:46 PM, Brad King wrote:
> On 06/08/2016 12:43 PM, Rolf Eike Beer wrote:
>>>  Run ranlib on archives only if the tool is available
>>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671
>> Shouldn't the first check also be "cmd == ":" instead of only
>> checking the first byte?
> No, because the command in question is actually ": libfoo.a".
> No valid command can start in ":" on any platform.
>
> -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] Bug in CMake: Generated Ninja files do not work on Windows

2016-06-08 Thread Brad King 
On 06/08/2016 12:43 PM, Rolf Eike Beer wrote:
>>  Run ranlib on archives only if the tool is available
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671
> 
> Shouldn't the first check also be "cmd == ":" instead of only
> checking the first byte?

No, because the command in question is actually ": libfoo.a".
No valid command can start in ":" on any platform.

-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] Bug in CMake: Generated Ninja files do not work on Windows

2016-06-08 Thread Rolf Eike Beer 
Am Mittwoch, 8. Juni 2016, 12:24:29 schrieb Brad King:
> On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote:
> > the : is obviously the default for noop which is correct for
> > Linux but not for Windows. My CMakeCache has the following entry:
> > //noop for ranlib
> 
> > CMAKE_RANLIB:INTERNAL=:
> I see that here:
> 
>  
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeFindBinUtils.cma
> ke;hb=v3.5.2#l55
> 
>   if(NOT CMAKE_RANLIB)
> set(CMAKE_RANLIB : CACHE INTERNAL "noop for ranlib")
>   endif()
> 
> Here is a fix:
> 
>  Run ranlib on archives only if the tool is available
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671

Shouldn't the first check also be "cmd == ":" instead of only checking the 
first 
byte?

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] Bug in CMake: Generated Ninja files do not work on Windows

2016-06-08 Thread Brad King 
On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote:
> the : is obviously the default for noop which is correct for
> Linux but not for Windows. My CMakeCache has the following entry:
> //noop for ranlib
> CMAKE_RANLIB:INTERNAL=:

I see that here:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeFindBinUtils.cmake;hb=v3.5.2#l55

  if(NOT CMAKE_RANLIB)
set(CMAKE_RANLIB : CACHE INTERNAL "noop for ranlib")
  endif()

Here is a fix:

 Run ranlib on archives only if the tool is available
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671

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] cmLocalGenerator::GetTargetFlags

2016-06-08 Thread Brad King 
Hi Tobias,

So it looks like I was completely wrong in pointing you at GetTargetFlags
to get compiler flags.  It is indeed for linker flags.

On 06/08/2016 04:23 AM, Tobias Hunger wrote:
> what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It 
> is
> only ever set for targets of type EXECUTABLE and is filled based on the 
> *linker
> language* of the target.
> 
> I really do not see any use for this information, and indeed the flag seems
> unused in the cmake code base, except for the Ninja generator, where that may 
> or
> may not make sense (probably not).

That is because when we invoke the C compiler to drive linking we pass
the compiler flags from CMAKE_C_FLAGS (and similarly for CXX).  For
non-executables the same thing is done in a different code path here:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmNinjaNormalTargetGenerator.cxx;hb=v3.6.0-rc1#l471

I think the comment about a mistake in the Ninja generator is telling.
The AddLanguageFlags is done there for non-executables and is done in
GetTargetFlags for executables.  This should be refactored and made
consistent.

> Can the flag get removed altogether and the method get renamed to
> GetTargetLinkerFlags?

+1 for renaming.  The best place for AddLanguageFlags to be called
needs to be determined.  Note that the Makefile generators use
cmCommonTargetGenerator::AddFeatureFlags to call AddLanguageFlags,
and that follows up with some additional flags for IPO.  That may
be another case that is broken in the Ninja generator.

> Maybe it could return the linker language instead, that is
> a piece of data that is more important in its context IMHO.

We already have cmGeneratorTarget::GetLinkerLanguage for that.

> While discussing this method: How about moving the method to 
> cmTargetGenerator?
> That would get rid of the target parameter. That is where I would actually 
> look
> for information on targets.

Yes, perhaps.  What may be more important is to consolidate this
with what the Makefile generator is doing.  There is no reason the
Ninja and Makefile generators to not share more code (and perhaps
other generators too, but VS and Xcode do not necessarily generate
the full command lines).  Once there is a single clear place for
this stuff to be computed then the daemon can use it with confidence.

> Which brings me back to my original question: How can I find the compiler 
> flags
> in use for a cmSourceFile/cmGeneratorTarget? The only place that I found that
> seems to do what I want is cmCommonTargetGenerator::GetFlags.

Yes, GetFlags it the correct place to get target-wide flags.  The Ninja
generator has cmNinjaTargetGenerator::ComputeFlagsForObject to also add
per-source flags.  The Makefile generator factors out the target-wide
flags into a make variable and then adds the same per-source flags
elsewhere.  The code that adds per-source flags should be factored
into a common helper that the daemon can then use along with GetFlags.

Side note: This is another thing that should be cleaned up in the Ninja
generator.  It should hold target-wide flags in the per-target rules.ninja
entries instead of duplicating them for every object file in build.ninja.
That would make the build.ninja files smaller.

> cmCommonTargetGenerator does caching of results. Should this be also done for
> cmLocalGenerator::GetTargetFlags, etc?

Not sure.  That is an optimization so may not be worth doing yet until
the needed refactoring is done first.

-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] FindBZip2: Add additional debug library name

2016-06-08 Thread Brad King 
On 06/07/2016 05:54 PM, Roger Leigh wrote:
> I've merged this bzip2-debug-names branch into next for testing.

Looks good, 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

2016-06-08 Thread Brad King 
On 06/08/2016 01:24 AM, Tobias Hunger wrote:
>>  cmLocalGenerator: Pass configuration to GetTargetFlags
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241
> 
> Great, thanks!

I had to revert it from 'next' because it caused several LinkFlags
test failures.  The reason is that it dropped UpperCase() on the
config name when called from the Ninja generator.  Please revise
accordingly in combination with the refactoring discussed in the
thread you started dedicated to that method.

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

2016-06-08 Thread Brad King 
On 06/08/2016 04:05 AM, Stephen Kelly wrote:
> I have rebased it and force pushed my github branch (there are a few
> rebasing mistakes which I'll remove later).

Thanks.

> We hit issues at work that different clang-format versions have
> different behavior. There we have the luxury of providing particular
> binaries that every developer uses to get identical results and no diff
> confusion.
> 
> I don't know how to solve that in CMake though. It could become an issue
> in the future when some contributors use clang-3.9 and others 3.8. Maybe
> clang-format binaries should be in the repo.

Right now we're using clang-format 3.8.  We'll worry about such
differences when they become a problem.

> Also, it seems that clang-format is not run by CI. The ProductBuild
> stuff doesn't seem to be clang formatted.

Yeah, we haven't gotten that set up yet.  Yesterday I added a topic
to 'next' to fix that formatting.

-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] cmLocalGenerator::GetTargetFlags

2016-06-08 Thread Tobias Hunger 
Hi everybody,

what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is
only ever set for targets of type EXECUTABLE and is filled based on the *linker
language* of the target.

I really do not see any use for this information, and indeed the flag seems
unused in the cmake code base, except for the Ninja generator, where that may or
may not make sense (probably not).

Can the flag get removed altogether and the method get renamed to
GetTargetLinkerFlags? Maybe it could return the linker language instead, that is
a piece of data that is more important in its context IMHO.

While discussing this method: How about moving the method to cmTargetGenerator?
That would get rid of the target parameter. That is where I would actually look
for information on targets.



Which brings me back to my original question: How can I find the compiler flags
in use for a cmSourceFile/cmGeneratorTarget? The only place that I found that
seems to do what I want is cmCommonTargetGenerator::GetFlags. Or is that
concerned about cmake internal flags that need to get mapped to compiler flags
later? Is there another copy of that code in a place more convenient to use or
do I need to create that?

cmCommonTargetGenerator does caching of results. Should this be also done for
cmLocalGenerator::GetTargetFlags, etc?

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

Re: [cmake-developers] CMake daemon-mode

2016-06-08 Thread Stephen Kelly 
On 06/07/2016 11:42 AM, Daniel Pfeifer wrote:
> On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:
>> On 06/06/2016 11:39 AM, Tobias Hunger wrote:
>>
>>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>>> cmake
>>> reformated all the source in the meantime it is a bit tedious to apply 
>>> patches
>>> from his tree and I have simply not yet needed the changes as I did not 
>>> venture
>>> where he went yet.
>> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
>> how to rebase across the style transition.  If you rebase the original
>> "cmake-daemon" branch on that then we can rewrite the style to make
>> cherry-picking later easier.
> When I rebased my own branches across the style transiton, I found the
> process quite straight forward.
> I can help with the style transition if someone rebases to 82df6deaaf.
>
> When I tried to rebase steve's work, it was not the style transition
> but changes like the following that I struggled with:
> https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355

I have rebased it and force pushed my github branch (there are a few
rebasing mistakes which I'll remove later).

We hit issues at work that different clang-format versions have
different behavior. There we have the luxury of providing particular
binaries that every developer uses to get identical results and no diff
confusion.

I don't know how to solve that in CMake though. It could become an issue
in the future when some contributors use clang-3.9 and others 3.8. Maybe
clang-format binaries should be in the repo.

Also, it seems that clang-format is not run by CI. The ProductBuild
stuff doesn't seem to be clang formatted.

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] Bug in CMake: Generated Ninja files do not work on Windows

2016-06-08 Thread Michael Jäntsch 

Ah ok. That is interesting. If I set the CMAKE_RANLIB (after my Project command) it gets executed correctly. Interesting is that this is not needed for mingw makefiles. I also do not know how to set the RANLIB properly in my toolchain file.

 

Either way, the : is obviously the default for noop which is correct for Linux but not for Windows. My CMakeCache has the following entry:

//noop for ranlib
CMAKE_RANLIB:INTERNAL=:

 

Michael

 

 

Gesendet: Dienstag, 07. Juni 2016 um 15:37 Uhr
Von: "Brad King" 
An: michael.jaent...@gmx.de
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

On 06/07/2016 02:07 AM, michael.jaent...@gmx.de wrote:
> problem is not the POST_BUILD which is set to "cd ." as you said but the
> CMAKE_CXX_ARCHIVE_FINISH which is before the POST_BUILD
[snip]
> command = ... D:\gcc\win32\mips-sde-elf\bin\mips-sde-elf-ar.exe qc $TARGET_FILE $LINK_FLAGS $in && : $TARGET_FILE && $POST_BUILD"

That is meant to be the "ranlib" call. The only way I was able to get
a ":" there was by setting -DCMAKE_RANLIB=: on the command line. What
is its value? See CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake
for a set(CMAKE_RANLIB) call. Does the toolchain provide a "ranlib"
tool?

-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