gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] CMake build system progress


From: Kevin Zheng
Subject: Re: [Gnucap-devel] CMake build system progress
Date: Thu, 22 May 2014 08:54:04 -0500
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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.

> 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.)

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.

Another issue I encountered was that the Makefile only worked with GNU
Make. This isn't a major problem because GNU Make is also available on
BSD, but CMake doesn't run into this problem.

> 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?

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.

CMake does automatic dependency scanning and tracking, so if the
configuration changes only the files that are affected are recompiled.
Autotools does something similar, but I don't believe that it scans for
header file dependencies.

> There are several steps.
> 
> 1. build libgnucap.so, using ../include headers (easy)

This is done!

> 2. build modelgen, which will link to the just built but not 
> installed libgnucap.so

This too!

> 3. build main, which will link to the just built libgnucap.so

And this!

> 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.

And this as well!

> 5. Install .. once installed the installed main and modelgen 
> need to use the correct installed libgnucap, and load the 
> correct plugins.

I'm just not certain what files should be installed, and where.

> 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.

Thanks,
Kevin Zheng



reply via email to

[Prev in Thread] Current Thread [Next in Thread]