Given that we're not going to change either llvm or libgit2 to use anything other than cmake, and other dependencies are increasingly adopting it as well, it's pretty much inevitable that we'll eventually use it if first-class MSVC support is ever going to happen. We're very much doing the wrong backwards thing by invoking cmake from gnu make, it's not designed for that workflow to do the right thing at all. I'm not surprised version upgrades confuse it.
On Thursday, October 27, 2016 at 7:27:08 AM UTC-7, Isaiah wrote: > > Or even better: let's remove a lot of complexity and move the whole Julia >> build system to CMake. > > > The main advantage I see to CMake is support for Visual Studio. I would > not consider it a reduction of complexity -- CMake is very much like > regexes: now you have two problems. Or perhaps three... > > set(number_problems 3 FORCE CACHE PARENT_SCOPE) > > I think I saw an issue about this some time > > > https://github.com/JuliaLang/julia/pull/11754 > > > On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens <[email protected] > <javascript:>> wrote: > >> >> On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton <[email protected] >> <javascript:>> wrote: >> >>> >>>> I'm not sure if there's any good way to introspect this and trigger a >>> reconfigure from Julia's build system without adding a lot of complexity. >>> >> >> Or even better: let's remove a lot of complexity and move the whole Julia >> build system to CMake. I think I saw an issue about this some time, so I >> guess it's non-trivial, but I'd be willing to help. >> > >
