automatically moving from cmake 3.6.1 to cmakex.y.z

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

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

Cheers,

Bart

On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

Federico Calboli

> On 27 Oct 2016, at 10:34, Bart Janssens <[hidden email]> 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

>
> Cheers,
>
> Bart
>
> On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

Federico Calboli

> On 27 Oct 2016, at 10:46, Federico Calboli <[hidden email]> wrote:
>
>
>> On 27 Oct 2016, at 10:34, Bart Janssens <[hidden email]> 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 <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

Isaiah Norton
In reply to this post by Federico Calboli
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*`.

On Thu, Oct 27, 2016 at 3:46 AM, Federico Calboli <[hidden email]> wrote:

> On 27 Oct 2016, at 10:34, Bart Janssens <[hidden email]> 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

>
> Cheers,
>
> Bart
>
> On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

Bart Janssens-2

On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

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



On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens <[hidden email]> wrote:

On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: automatically moving from cmake 3.6.1 to cmakex.y.z

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.


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

<a href="https://github.com/JuliaLang/julia/pull/11754" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fpull%2F11754\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFktqcVYPYRLaL3wOyVNu8tXsHbeg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fpull%2F11754\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFktqcVYPYRLaL3wOyVNu8tXsHbeg&#39;;return true;">https://github.com/JuliaLang/julia/pull/11754


On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="hobwIRkOAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">ba...@...> wrote:

On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="hobwIRkOAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">isaiah...@...> 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.