Cmake build files in external

[Keno]

These are the cmake related commits, cherry-picked out of #521. I'm putting it up in case somebody wants to object to having these in master before the rest of the changes. Otherwise, I'll merge it into master tonight.
Keep in mind that these files are only a rough basis for a complete Cmake build process. I used them during the initial phase of the windows port when I had to rebuild the dependencies quite often. The long term goal for these files is to allow us to do more advanced builds (e.g. cross-compilation) and to support environments that do not support gmake (i.e. MSVC).

[StefanKarpinski]

I would be willing to switch our build system over to cmake for the sake of portability. I don't particularly love gmake.

[Keno]

Currently the cmake files are not quite ready yet and using them is not as easily done as it could be. I haven't touched this stuff in two months, however, and back then it was mostly about getting the dependencies to run properly on Windows when gmake fails or is slow (make -jN is horribly broken on windows, which as you might expect is quite a problem if you have to rebuild dependencies often). I will work on this again after the rest of the libuv changes are done and integrated into master, but for now, I just wanted to pick this apart as a separate pull request.

[StefanKarpinski]

Should this be an RFC pull request then?

[pao]

We should probably ensure that Linux and Mac builds work with this, and cc @ViralBShah to comment on potential conflicts with what he's doing on the local_blas branch.

[StefanKarpinski]

I just installed cmake. How do I build julia with it?

[Keno]

This may still be useful for people having trouble with gmake (as I said particularly on windows) and building the dependencies in external/. Now, we could keep this in the cmake branch until it's perfectly done, but given that this does not modify any files and that we want to slowly merge the windows support into master, I figured it would be best to get this out of the way.
It's good to have this discussion however, and that's what I wanted from this pull request. To me marking it as RFC would mean "don't merge until the changes are reviewed and I add some more features", while this is more like a "I think we should merge this, but if there are reasons not to that's ok"

[ViralBShah]

Let's get cmake to work fine for the windows build, and complete the windows merge. After that, let's use it on Mac and Linux if we like it. I don't mind the extra dependency - but let's stay with gmake for the time being. I have a bunch of stuff on the local_blas branch that I want to merge into master before we attempt moving to cmake.

-viral

On 29-Apr-2012, at 1:12 AM, Keno Fischer wrote:

This may still be useful for people having trouble with gmake (as I said particularly( and building the dependencies in external/. Now, we could keep this in the cmake branch until it's perfectly done, but given that this does not modify any files and that we want to slowly merge the windows support into master, I figured it would be best to get this out of the way.
It's good to have this discussion however, and that's what I wanted from this pull request. To me marking it as RFC would mean "don't merge until the changes are reviewed and I add some more features", while this is more like a "I think we should merge this, but if there are reasons not to that's ok"

---

Reply to this email directly or view it on GitHub:
#771 (comment)

[Keno]

@StefanKarpinski As the title says, this is currently just for building some of the dependencies in external/ and not for a complete Julia build.
In any case, you should be able to try that out using:

cd external
mkdir build
cd build 
cmake .. && make -j8 && make install

P.S: Ignore the spelling mistake during the build, I'll fix it ASAP.

[Keno]

@ViralBShah Yes, that is the intention for this.

[pao]

And looks like I misunderstood the scope, so no need to check Mac/Linux yet.

[Keno]

Not really. I mean, I used it on Ubuntu to be able to rapidly switch between debug/release builds of LLVM, but other that that it's not too useful (yet).

[Keno]

@StefanKarpinski @ViralBShah @pao (and @JeffBezanson) Just to be clear, does anybody have a problem with merging this into master, given that it is just going to exist in parallel and does not change the existing build process?

[pao]

I'm satisfied, now that I understand what's going on.

[StefanKarpinski]

Yeah, cool with me.

[Keno]

Let's do this then.

[ViralBShah]

Go for it.

-viral

On 29-Apr-2012, at 4:13 AM, Keno Fischer wrote:

@StefanKarpinski @ViralBShah @pao (and @JeffBezanson) Just to be clear, does anybody have a problem with merging this into master, given that it is just going to exist in parallel and does not change the existing build process?

---

Reply to this email directly or view it on GitHub:
#771 (comment)

[tkelman]

Can someone summarize the history of what happened with these? They were removed at some point, but it might be worth bringing some of these back for arpack, amos, fftw, openlibm, etc in connection wtih #11754. If there were some patches for these on master, would want to dig up and start from the most recently used versions of them.