[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] CMake build system progress
From: |
al davis |
Subject: |
Re: [Gnucap-devel] CMake build system progress |
Date: |
Tue, 10 Jun 2014 22:34:17 -0400 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
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.