These are chat archives for inbilla/CMake

21st
Mar 2016
Joshua Green
@inbilla
Mar 21 2016 03:30
Getting closer....

I've broken 1 extra test though (CustomCommand).

97% tests passed, 12 tests failed out of 372

Label Time Summary:
Label1 = 0.39 sec
Label2 = 0.39 sec

Total Test time (real) = 2302.76 sec

The following tests FAILED:
59 - Preprocess (Failed)
70 - ConfigSources (Failed)
100 - SubProject (Failed)
108 - CustomCommand (Failed)
113 - BuildDepends (Failed)
114 - SimpleInstall (Failed)
115 - SimpleInstall-Stage2 (Failed)
132 - ExternalProjectLocal (Failed)
134 - ExternalProjectUpdate (Failed)
157 - PrecompiledHeader (Failed)
276 - RunCMake.Configure (Failed)
372 - CMake.CheckSourceTree (Failed)
Errors while running CTest

heaps closer - running out of things to solve inside CMake
more and more need to be done in FASTBuild
Packadal
@packadal
Mar 21 2016 08:04
yeah, I tried rebasing, it will not be easy work, lots of things changed inside CMake
and I tried on linux, having a clean solution for running multiple exes will be a must
because on linux CMake links in two commands 'a && b'
and having a bash script for each target soes not sound like a solution
Joshua Green
@inbilla
Mar 21 2016 10:36
What kind of things have changed?
Joshua Green
@inbilla
Mar 21 2016 10:43
@rkhoury was working on getting the Linux side of things working
@rkhoury - how did that go? Did you get anything working in the end?
Did you end up having a plan for the a && b command structure?
Packadal
@packadal
Mar 21 2016 13:10
lots of things have moved to cmState, lots of function renaming
some are trivial, some are not
I'm trying again, but rebasing bit by bit (I'm trying to get it to wotrk on CMake 3.3.0 now)
Packadal
@packadal
Mar 21 2016 13:35
CMake 3.3 seems to be OK, tests are running
Packadal
@packadal
Mar 21 2016 14:50
64% tests passed, 137 tests failed out of 380
quite a few regressions, but this kinda works
Packadal
@packadal
Mar 21 2016 15:16
porting to CMake 3.4 is more involved, there are lots of stuff that moved from cmTarget to cmGeneratorTarget
I am trying a dumb port, but I don't think it makes sense, lots of the logic should be reviewed because I get the feeling (without delving into the code really) that some of the custom logic is not necessary anymore
since cmGeneratorTarget seems to offer (at least) some of it