WIP/RFC: add cmake build system

[twadleigh]

Addresses #1832.

• build Julia on one platform (*nix) with one configuration (whatever you get when throwing the fewest flags)
  • libsupport
  • lib/flisp
  • libjulia
  • the julia exe
• extend to:
  • all platforms
  • multiple configurations
  • dependencies
  • the dist target

[twadleigh]

I've been stuck with this error for the last couple of attempts to make progress on this:

[ 50%] Building C object src/CMakeFiles/libjulia.dir/sys.c.o
/home/tracy/prj/julia/src/sys.c: In function ‘jl_pathname_for_handle’:
/home/tracy/prj/julia/src/sys.c:655:5: warning: implicit declaration of function ‘dlinfo’ [-Wimplicit-function-declaration]
     dlinfo(handle, RTLD_DI_LINKMAP, &map);
     ^
/home/tracy/prj/julia/src/sys.c:655:20: error: ‘RTLD_DI_LINKMAP’ undeclared (first use in this function)
     dlinfo(handle, RTLD_DI_LINKMAP, &map);
                    ^
/home/tracy/prj/julia/src/sys.c:655:20: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [src/CMakeFiles/libjulia.dir/sys.c.o] Error 1
make[1]: *** [src/CMakeFiles/libjulia.dir/all] Error 2
make: *** [all] Error 2

Of course, I'll continue to try to decode the current Makefile, but I'm posting to solicit shortcuts from the community.

[few]

You need to pass -D_GNU_SOURCE to gcc.

[twadleigh]

Thanks @few. That got me a tick further.

[tkelman]

Very cool, a good start so far. Before you get too much further, can we prefer spaces instead of tabs please?

And as I said in an email I think we'll need to put in some code at some point to check what generator is being used, and fail on in-tree builds for any generators that would overwrite the makefiles.

[ihnorton]

We might want to fail outright for in-tree builds with CMake. This has been the policy (born of experience) of every CMake-based application I have worked on and AFAIK is the policy for Kitware products. (one of the issues is that CMake can't track most of the files that end up being created via the platform build system, so getting a clean directory is hard). In-tree restricted to a dedicated subdirectory is probably fine though.

[tkelman]

We might want to fail outright for in-tree builds with CMake.

Maybe not a bad idea. Since this gives us out-of-tree builds right away, may as well forcefully encourage their use. Easier to skip the logic of figuring out what generator we're using, too.

CMake can't track most of the files that end up being created via the platform build system, so getting a clean directory is hard

We could probably let git do that part for us, no?

[tkelman]

I think this can be closed in lieu of the further-along #11754. Your input there would be welcomed - we'll want to borrow your snippet to ban in-tree cmake builds once the newer PR gets to be independent of the existing makefiles.