Re: [Gnucap-devel] CMake build system progress

[al davis]

On Thursday 22 May 2014, Kevin Zheng wrote:
> On 05/22/2014 00:19, al davis wrote:
> > Later, when the configure;make protocol caught on, the
> > configure script simply generated the appropriate Make2.
> 
> The problem I initially encountered was that `configure` did
> not pick up a few settings that I wanted, which meant that I
> needed to swoop in and edit Make2 myself. This was also
> confusing because I didn't understand the purpose of
> Make1/2/3.

At least you could do that, and that is because the system was 
designed before the autotools or cmake or anything  like them 
existed.  Back then, a choice of Make2's covered a lot of 
systems.

I stopped developing it when I thought there was no longer a 
need, hoping for things like autotools to takeover.  In a way, 
they have, but I find the quality disappointing.
 
> CMake takes a different approach by generating a build
> system. You run CMake to produce Makefiles, Visual Studio
> projects, etc., and then build the project with those. This
> seems more modular to me, especially for systems without
> make.

It really isn't all that different.  My biggest objection to 
CMake is that it creates another dependency.

One important test of a build system is to try to configure and 
compile on a completely empty system, with nothing but the 
minimum installed, not even the compiler.  The configure system 
should guide you  through the process of installing what you 
need.  As a minimum, it should handle the missing tools and 
libraries better than just compiling and noticing where the 
compile fails.  Often, this isn't true.

After passing that one, the next test  is to do a similar test 
from a student account in a university, where you don't have 
root and the sysadmin doesn't want to be bothered with your 
nutty requests.

Not saying the "old" system passes this test, but at least the 
files are editable.

> I encourage you to compare 'lib/Make1' with
> 'lib/CMakeLists.txt'. For autotools, the equivalent will be
> 'lib/Makefile.am'. In my highly-biased opinion, CMake has
> the cleanest per-directory Makefile.

They are really not much different when you compare in a 
meaningful way.  The extra stuff in Make1 is to do things like 
the distribution tarball, "make clean" "make distclean" "make 
rcs" (the old revision control system).  You really need to 
specify that stuff.  Leaving it to auto-whims doesn't cut it.

The syntax used by CMake may be nicer, but it is not the same as 
Make, and there is no real reason to depart from Make syntax.

If I am rearranging (as to do the split build) I want something 
that looks like just a simple Makefile, unburdened by the other 
stuff.  The fact that converting to both autotools and CMake is 
nontrivial, and the fact that the converted files are not 
smaller and simpler than the original, points out the need to 
keep the old system.

> > Cross compiling ...  You really need to build the native
> > version and use it to cross-compile.  The critical part is
> > modelgen, which needs libgnucap.
> > 
> > It may be reasonable to require that to cross compile you
> > need to have a native version installed, but then which
> > modelgen do you get?
> 
> I'll need to work on cross-compiling. It makes the most sense
> to build the native modelgen without using anything that's
> pre-installed.

Again, I think it is reasonable to expect that to cross-compile 
you must have a native version installed.  Then the difference 
between "cross" and "native" aside from which compiler and 
libraries to use is that "cross" would use the installed 
modelgen and check the headers for compatibility, but "native" 
would use the modelgen and headers being built.

Otherwise, it would really need to build twice, when most likely 
the native version IS already installed.

It could go either way.  I am thinking what is easier, because 
harder may never happen.