make: work on the build system

we could write a unix Makefile, and an nmake Makefile quite easily using J.
this way, we won't have the double maintenance of two slightly different files.
i would favour this approach this if there is no need for VC++ projects/solution.
however, i reckon there is that need.

i'm not brave enough to try it, but maybe someone would like to see if it's
feasible to generate VC++ projects/solution in the same way as generating gmake
or nmake makefiles.

[effbiae]

CMake can generate Makefiles, nmake Makefiles and Visual Studio projects/solutions from the one source:

CMakeLists.txt

project(j)

add_library(j a.c ab.c af.c ai.c am.c am1.c amn.c ao.c ap.c ar.c as.c au.c c.c ca.c cc.c cd.c cf.c cg.c ch.c cip.c cl.c cp.c cpdtsp.c cr.c crs.c ct.c cu.c cv.c cx.c d.c dc.c dss.c dstop.c dsusp.c dtoa.c f.c f2.c i.c io.c j.c jdlllic.c k.c m.c mbx.c p.c pv.c px.c r.c rl.c rt.c s.c sc.c sl.c sn.c t.c u.c v.c v0.c v1.c v2.c va1.c va2.c va2s.c vamultsp.c vb.c vbang.c vbit.c vcant.c vchar.c vcat.c vcatsp.c vcomp.c vcompsc.c vd.c vdx.c ve.c vf.c vfft.c vfrom.c vfromsp.c vg.c vgauss.c vgcomp.c vgranking.c vgsort.c vgsp.c vi.c viix.c visp.c vm.c vo.c vp.c vq.c vrand.c vrep.c vs.c vsb.c vt.c vu.c vx.c vz.c w.c wc.c wn.c ws.c x.c x15.c xa.c xb.c xc.c xcrc.c xd.c xf.c xfmt.c xh.c xi.c xl.c xo.c xs.c xt.c xu.c)

add_executable(jconsole jconsole.c jeload.c)

target_link_libraries(jconsole j dl)

Running CMake

cmake "Unix Makefiles" . && make -f Makefile

Other Targets

CMake can also generate these targets:
* Borland Makefiles
* MSYS Makefiles
* MinGW Makefiles
* NMake Makefiles
* NMake Makefiles JOM
* Unix Makefiles
* Visual Studio 10
* Visual Studio 10 Win64
* Visual Studio 6
* Visual Studio 7
* Visual Studio 7 .NET 2003
* Visual Studio 8 2005
* Visual Studio 8 2005 Win64
* Visual Studio 9 2008
* Visual Studio 9 2008 Win64
* Watcom WMake
* CodeBlocks - MinGW Makefiles
* CodeBlocks - NMake Makefiles
* CodeBlocks - Unix Makefiles
* Eclipse CDT4 - MinGW Makefiles
* Eclipse CDT4 - NMake Makefiles
* Eclipse CDT4 - Unix Makefiles

Prefer something else?

maybe a way ahead is to write a makefile generator (in j) that outputs Unix Makefiles and Windows Makefiles and have other "non core" "build system repos" that provide alternate build systems.

[sofuture]

I think CMake or Autotools is a good idea. I'm partial to Autotools, but that's just baseless bias -- I don't have non-end-user experience with either :)

I've done some Makefile work in a branch on my fork that replaces jconfig -- but nothing worth including so far (the flags are all specific to my system).

[effbiae]

yeah, i fiddled around and wrote a (kind of) ./configure script (non auto-tools). i queued it up for merging into openj/core, but it's just a simplification of what's in bin/

"don't have non-end-user experience" now that's a juicy statement... i don't think i've ever not heard a phrase not like that :)

[effbiae]

i've been concerned that we may have multiple build systems in core. maybe i should relax :) now, i think we can have multiple build systems (maybe reading the $SRC from Makefile.am - use it as the master).

i was concerned about some windows users getting confused or "turned off" by anything but Visual Studio project files and .c and .ijs files in the repo. then i realised that this is what make dist is for - for windows users, we just publish an openj-src.zip that is nice and tidy with just the VC++ project files

now i think we can retire the short lived 'configure' script and move to autotools.

[smarter]

What about Windows devs that want to contribute to the development? IMHO, the autotools are an outdated mess. And CMake requires much less boilerplate. See for example the reasons why KDE switched to CMake for KDE4: http://lwn.net/Articles/188693/

[effbiae]

see the gencmake shell script here https://github.com/effbiae/core/tree/cmake

git for windows comes with a bash shell, so gencmake should run just fine there. at the moment, gencmake reads Makefile.am, but we could have a simpler master source list like this:
EXESRC="jconsole.c jeload.c"
EXESRC="a.c ab.c af.c ai.c am.c ....
that inputs to a general genXXX script to generate CMakeLists.txt and Makefile.am files

[smarter]

I just pushed a decent CMakeLists.txt here: https://github.com/smarter/core/commits/cmake
It could be integrated with your gencmake, though I'm still not sure if we need it.

[effbiae]

i don't think everyone will be happy with CMake -- same goes for autotools.

if we use both cmake and autotools, we want to eliminate the double maintenance of the source list and other config that can be generalized. gencmake is an example of eliminating double maintenance, but better solutions are welcomed.

maybe in the future, one build system will prevail over others and we won't have a double maintenance problem.

[sofuture]

I'd like to see a single CMake file (or Autotools, really) -- I don't think we should take on double maintenance of anything. You can't please everyone and it looks like either option works -- either way, once we pick one we can move forward.

Count this as a vote for CMake, I guess.