automatically moving from cmake 3.6.1 to cmakex.y.z

[Federico Calboli]

Hi, toady on a whim I tried 

make cleanall && make testall

but it did not work because when julia was built cmake was at 3.6.1 and now it is a 3.6.2

make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory

make[2]: *** [cmake_check_build_system] Error 1

make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2

make: *** [julia-deps] Error 2

Now I have:

../Cellar/cmake/3.6.2/bin/cmake

This problem seems extremely silly, given that it forces me *not* to upgrade my cmake (and maybe other software), when the make routine could do the equivalent of `which cmake' and use the result.  

Leaving this aside, is there a way of rebuilding julia with the correct cmake without basically removing the whole thing and rebuilding from 0?

BW

F

[Bart Janssens]

Normally this is solved by running "cmake ." in the build directory or directories of the library or libraries compiled using cmake.

Cheers,

Bart

[Federico Calboli]

> On 27 Oct 2016, at 10:34, Bart Janssens <ba...@bartjanssens.org> wrote:
>
> Normally this is solved by running "cmake ." in the build directory or directories of the library or libraries compiled using cmake.

Thanks! is there a way of doing it automatically and recursively until it finds the appropiate CMakeLists.txt file so I do not have to trawl for it? in addition, as it seems pretty simple I am surprised this does not happen ‘automagically’.

BW

F

[Federico Calboli]

> On 27 Oct 2016, at 10:46, Federico Calboli <f.ca...@gmail.com> wrote:
>
>
>> On 27 Oct 2016, at 10:34, Bart Janssens <ba...@bartjanssens.org> wrote:
>>
>> Normally this is solved by running "cmake ." in the build directory or directories of the library or libraries compiled using cmake.
>
> Thanks! is there a way of doing it automatically and recursively until it finds the appropiate CMakeLists.txt file so I do not have to trawl for it? in addition, as it seems pretty simple I am surprised this does not happen ‘automagically’.

Actually I found where to run "cmake .” and it seems to work (even if I realised that I did not fix the utf8 library…). In any case the fact I have to do by hand it is perplexing…

BW

F

> BW
>
> F
>
>>
>> Cheers,
>>
>> Bart
>>
>> On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli <f.ca...@gmail.com> wrote:
>> Hi, toady on a whim I tried
>>
>> make cleanall && make testall
>>
>> but it did not work because when julia was built cmake was at 3.6.1 and now it is a 3.6.2
>>
>> make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory
>> make[2]: *** [cmake_check_build_system] Error 1
>> make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
>> make: *** [julia-deps] Error 2
>>
>> Now I have:
>>
>> ../Cellar/cmake/3.6.2/bin/cmake
>>
>> This problem seems extremely silly, given that it forces me *not* to upgrade my cmake (and maybe other software), when the make routine could do the equivalent of `which cmake' and use the result.
>>
>> Leaving this aside, is there a way of rebuilding julia with the correct cmake without basically removing the whole thing and rebuilding from 0?
>>
>> BW
>>
>> F
>
>
>

--
Federico Calboli
f.ca...@gmail.com

[Isaiah Norton]

Thanks!  is there a way of doing it automatically and recursively until it finds the appropiate CMakeLists.txt file so I do not have to trawl for it? in addition, as it seems pretty simple I am surprised this does not happen ‘automagically’.

The generated Makefiles have absolute, symlink-resolved paths because CMake doesn't want the version to change underneath (I guess?). But the cmake binary itself is called back by make to detect whether a reconfiguration is necessary. Hence this error.

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. If you want to figure out which projects to reconfigure: `find /path/to/julia -name *CMakeCache*`.

[Bart Janssens]

On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton <isaiah...@gmail.com> 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.

[Isaiah Norton]

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

[Tony Kelman]

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.