a ready to use build file

[jgonggrijp]

We should have something like a portable makefile, now assuming CMake, that takes care of most of the chores for those who add compiled programs to the project. The makefile itself should reside in RED_SPIDER_ROOT, any intermediate build results (including generated platform-specific makefiles) should go into the build directory, and installation targets should go into bin, extbin or lib depending on what's being built. It should also be possible to override the latter directories. Once the makefile is ready, a hacker shouldn't need to add much more than a line of the following form in order to have their program built and installed:

add_executable(programname source.xyz)

CMake is very powerful and this shouldn't be too hard to achieve, but I'll need to study it before I can pull it off. Some help from anyone with experience in CMake would be much appreciated.

For the commands written in an interpreted language, which are currently handled by setup.py, we can use the information from this StackOverflow answer.

[jgonggrijp]

Quote @firerogue in #21:

Even better would be, once we have a proper setup/configure script, to have a --dev flag, that would make all kinds of changes in the source to make the final programs more developer friendly (maybe set debug flags and the like) since I'm sure that as the project gets more complex, a useful development build may look increasingly more different than a non-development build.

I think this would be a good idea, and if I'm right CMake has built-in facilities for that kind of thing.

[jgonggrijp]

A lot of information regarding language support can be found starting from here, with some effort:
http://www.cmake.org/Wiki/CMake:Module_Maintainers

It appears that several languages are available in CMake out of the box, including assembly, Fortran, Ada, D, Java and the entire Perl family (Perl, Python, Ruby, PHP).

This one is very useful for C# in particular (also relevant to @BRNMan's xkcd-windows-wallpaper):
http://sourceforge.net/p/gdcm/gdcm/ci/master/tree/CMake/

Discussions from which I found the latter:
http://www.cmake.org/pipermail/cmake/2008-October/thread.html#24632

My overall impression is that CMake isn't very well documented (at least not to the point in one easy to find spot), but that it might be powerful enough that we would still want to use it.

[lramati]

Given what I'm trying to do with the new setup script, I think this issue can be closed.
To recap, under the new system, any build instructions your additions require should be placed in the build/ directory in the form of an executable file which will get called from command line by the setup and update scripts. The exact details might still need some work, but in any case there is no longer a single global build file as this issue suggests.

[jgonggrijp]

I disagree, because building compiled programs can be complicated and build systems like CMake exist for a reason. Writing our own build scripts from scratch would be needless effort. Moreover, I think adding a new compiled program should be accessible as possible. For that reason I think a build file still deserves some priority. I already started working on it.

[mrhmouse]

@jgonggrijp Wouldn't the changes suggested by @firerogue allow you to still use CMake/Make/an appropriate build tool per program?

@firerogue Correct me if I'm wrong, but your setup script will just call the executable in my_program/build, yes? So, I could have a build/ directory like:

- my_project/
  - build/
    build
    Makefile
    my_project.c

where build is my exectuable, which would just call make.

[lramati]

I'm arguing for a decentralized build system, while @jgonggrijp is arguing
for a centralized one. He wants a single build file that'd build
everything, while I want build/{fetch.sh, help.sh, raptor.py, foo.make}
and then my script would call ./build/fetch.sh, ./build/help.sh etc.

My two biggest points are

1. it simplifies merging when you have 3 different programs being written
   simultaneously, which also makes it much easier to add 3rd party or your
   own programs (drop a file into a folder vs trying to merge two versions of
   a complex build file)
2. it also allows you to use any build mechanism you're comfortable with,
   and reduces complexity for simpler things (a shell script with a call to cp
   or mv instead of mucking with Cmake

@jgonggrijp's argument is that it simplifies things for first time hackers,
which I think is a good idea, but better served by a few example build
files installed with a developer build

As a nonsequitor, should we try to write a devifier (seperate script or
option in a current one) that would allow you to switch from a user install
to a dev one (and maybe back?)

[jgonggrijp]

I'm fine with distributed build files instead of a centralized one. However, I don't think we should just drop an old plan which somebody already started working on simply because we thought of another way to do it (unless the new plan is in a more completed state than the old one, but that's not the case here). There's nothing wrong with having two alternative plans being worked on at the same time; let's see how both develop, and then pick which one we like best. In fact, my centralized build file could be useful even if it only functions as a temporary solution until @firerogue's idea is completed.

Merging is almost never a problem with Git, but I accept the second point on letting people choose which build system they want. That could also be a disadvantage though, because users will probably need to have more external dependencies installed simply to install the software. I guess time will tell; if we get annoyed because of all the build tool dependencies, we can always switch back to a centralized build system.

I'm absolutely fine with a separate presentation of affairs specifically for devs. I thought we already agreed on that before!

[lramati]

I know, which is why I've started suggesting things to actually do with it