These are chat archives for inbilla/CMake

Nov 2016
Nov 01 2016 00:01 UTC
There is a thread on the CMake mailing list, and it would be OK for a first version to be Windows only, but Linux support would be awesome
I have very limited time to work on this, so I'm focusing on windows for now
Nov 01 2016 05:48 UTC
Well, that is perfect. I'd like to test the depth of the water and see if I can help with something. I am linux only (can use mac too), but wont work on windows.
I'll sync with you when I make new build and run the tests. I can test on mac too, but I do not expect there is any value in that at this stage.
Nov 01 2016 07:01 UTC
Awesome! If you run into any trouble, ask away
Nov 01 2016 07:54 UTC

Rebuilt cmake with cmake on linux (with gnu make generator) and run tests and these are failing:

The following tests FAILED:
192 - CTestCoverageCollectGCOV (Failed)
393 - RunCMake.CommandLine (Failed)
401 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed)
409 - RunCMake.CPack_RPM (Failed)
410 - RunCMake.CPack_TGZ (Failed)
Errors while running CTest

Then got cmake configured with fastbuild. That worked. The fbuild.bff is not good. fbuild -showtargets gives error:

fbuild.bff(340,36): FASTBuild Error #1009 - Unknown variable.
.BaseLinkerOptions = '-E remove $TARGET_FILE && /usr/bin/ar qc $FB_INPUT_2_PLACEHOLDER$ $LinkFlags$ $LinkPath$ $FB_INPUT_1_PLACEHOLDER$ && /usr/bin/ranlib $FB_INPUT_2_PLACEHOLDER$ '

I'll have a look at it at the evening. My timezone is Central European Time ... Will let you know when I have more.

Nov 01 2016 08:07 UTC
Ah this is gonna be trouble
(not the error, I think it cN
Can be fixed easily
But there is a '&&' in the link command, which fastbuild does not like
Fastbuild invokes executablez directly, without creating a shell instance, thus '&&' will be treated as a parameter
I remember looking into it quickly, but this has to do with CMake's linker management, as this command is provided by CMake
So this may be tricky
Joshua Green
Nov 01 2016 09:38 UTC
Packadal, we already deal with that by outputting script files and using those as the commands.
That is why linker type can be specified directly
Because fastbuild originally always auto detected the linker type. Which meant script files weren't going to work. But it should be fine to do now.
Just output the link commands to a script file, and set that as the link command. Then set the linker type of the link node to whatever makes sense for the compiler
Nov 01 2016 11:04 UTC
Oh right, forgot about specifying the linker type
Thanks :-)
BTW this is something that could be easily improved upon, only generating the script file when the command contains '&&'
There could be false positives, but still much better than what we have now
Nov 01 2016 20:48 UTC

In the output I showned from fbuild -showtargets:

  • && are not what fbuild complains about
  • $TARGET_FILE should have been $TARGET_FILE$ (typo in cmFastbuildTargetGenerator::ComputeLinkCmds())
  • .TARGET_FILE itself is not defined
  • .TargetOutSO is not defined. Both TARGET_FILE and TargetOutSO are used in BaseLinkerOptions

I'd expect the above problems to be present on windows too? Does fbuild -showtargets work for you on windows? My next step is to study the code so that I can fix later 2 issues.

Yes, of course all your arguments are valid about the presence of && in the command line if fbuild does not run it via a shell.