[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: |
Thu, 22 May 2014 01:19:38 -0400 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
On Tuesday 20 May 2014, Kevin Zheng wrote:
> I encourage people and fed-up Autotools developers
> to try out what CMake has to offer
:-)
Some background ....
The "old" build system that I keep falling back to is really
just a modular Makefile. When I started doing it that way ..
Autotools didn't exist. The target systems were Sun3 (68k),
Sun4 (Sparc), SGI, VAX, HPUX, NeXT (68k), IBM-AIX (PowerPC) ....
Linux didn't exist. At the university where I was teaching,
they had all these sharing the home directory.
The solution was the 3-part Makefile. Make1 is specific to this
program, this directory. Make2 customizes to the target. Make3
is boilerplate, constant everywhere. It really worked well
compared to what else was available at the time.
Cat the 3 parts because Make did not include. A new target
meant a new Make2, which was used for all programs on that new
target.
Later, when the configure;make protocol caught on, the configure
script simply generated the appropriate Make2.
This system worked, even on non-unix systems like VMS, Apple
(old Mac-OS, 68k), and MS-DOS (Intel 80286). (Windows-2 was
available, but hadn't caught on. It was astonishingly bad.)
I still like this approach. It's modular. You have a choice of
how you want to do the configuration. Looking at Make1, it
seemingly adds no complexity compared to a plain Makefile.
My wish ... Can we keep this modularity and use autotools or
cmake to generate that Make2? and use the autotools or cmake
provided boilerplate part to replace the woefully incomplete
Make3? and keep the ability to edit and go without recompiling
on Make1?
Back to the present ..
The build process, with split build ..
There are several steps.
1. build libgnucap.so, using ../include headers (easy)
2. build modelgen, which will link to the just built but not
installed libgnucap.so
3. build main, which will link to the just built libgnucap.so
4. build "apps". Some files here require modelgen to compile
them. It needs to be the modelgen just built, which links to
the libgnucap just built, and use the include files in
../include.
5. Install .. once installed the installed main and modelgen
need to use the correct installed libgnucap, and load the
correct plugins.
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?
- Re: [Gnucap-devel] CMake build system progress, (continued)
- Re: [Gnucap-devel] CMake build system progress, Felix Salfelder, 2014/05/20
- Re: [Gnucap-devel] CMake build system progress, Kevin Zheng, 2014/05/22
- Re: [Gnucap-devel] CMake build system progress, Felix Salfelder, 2014/05/22
- Re: [Gnucap-devel] CMake build system progress, Kevin Zheng, 2014/05/22
- Re: [Gnucap-devel] CMake build system progress, Felix Salfelder, 2014/05/22
- Re: [Gnucap-devel] CMake build system progress, Kevin Zheng, 2014/05/24
- Re: [Gnucap-devel] CMake build system progress, Felix Salfelder, 2014/05/24
- [Gnucap-devel] RPATH? Was: Re: CMake build system progress, Felix Salfelder, 2014/05/26
- Re: [Gnucap-devel] RPATH? Was: Re: CMake build system progress, Kevin Zheng, 2014/05/26
- Re: [Gnucap-devel] CMake build system progress, al davis, 2014/05/23
Re: [Gnucap-devel] CMake build system progress,
al davis <=