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: Felix Salfelder
Subject: Re: [Gnucap-devel] CMake build system progress
Date: Thu, 22 May 2014 09:44:04 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, May 22, 2014 at 01:19:38AM -0400, al davis wrote:
> 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.

well. what you did is pretty close to automake. except that it's
non-standard. and autotools has a number of features that i consider
useful. (i don't know much about cmake.)

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

variables like CCC (CXX in GNU world), CXXFLAGS etc are set and can be
overriden during configure. what's the use of spelling them out
seperately in various Make2.* files? please give an example.

> and keep the ability to edit and go without recompiling 
> on Make1?

depends on what you edit (?). the dependency tree for the build system
is created by autotools. compilation dependencies are written out by
$(CXX). these are intended to be minimal. if they are not, its possibly
a bug.

> There are several steps.
> 
> 1.-5. [..]

this is what a build system does. as it seems, the static/old build
system fails on 5. (or did i do something wrong?)

> Cross compiling ...  You really need to build the native version 
> and use it to cross-compile.  The critical part is modelgen, 
> which needs libgnucap.

variables set in makefiles can be overriden at command line.
if you have modelgen installed, just type

make MODELGEN=/path/to/some/other/modelgen (*)

instead of

make

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

the way to go is "use configure". two options come to mind
- a cross compile option (e.g. --with-cross)
  look out for modelgen within $PATH, check whether the version is
  correct, complain otherwise
- select modelgen manually, --with-modelgen=/this/or/that/modelgen
  functionally equivalent to (*), allows to shoot yourself in the foot.

anyway, since (*) is already there, i'd rather not implement this in a
more sophisticated manner. anything i overlooked?

thanks
felix



reply via email to

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