[Botan-devel] botan build configuration

[Jack Lloyd]

[CC'ed to botan-devel as there has been discussion of this recently
on there as well]

On Mon, Aug 28, 2006 at 08:59:20AM +0200, Luca Piccarreta wrote:
> Hi Jack,
> I hope you remember me... the x-kad guy which kind of played
> with botan a few months ago.... Luca Piccarreta.

Hi Luca, of course I remember. The asm you sent has been working very
well. :)

> I'm integrating the latest botan version.
> I'm afraid there are a couple of problems with Visual C++ 2003,
> mostly compiler errors, I suppose.
> I kind of fixed them, I'll send you the code with workarounds.

Yes, some other people also mentioned them just recently. I'm going to
be taking a look at those tonight.

> Once more... I understand this is about coding style, but I really
> don't like the "build directory" creation with symlinking and stuff...
> I can't see any clean of way of hosting multiple builds on the
> same code base. (Well... there is one, playing with the "build"
> dir and making its name dependent on target processor)

Yes, actually several people have brought up similar concerns and it
probably would be useful. I think this will not be terribly hard to
support; someone else has sent patches which I haven't had a chance to
look at, but my initial thought is that adding a --build-dir=<dir>
command to configure would allow for multiple builds on different
platforms. And actually it might be interesting to place the Makefile
into build/ (or whatever the user specifies) so multiple
configurations don't stomp on each other.

That would also allow for out of tree builds which might be useful
in some package building scenarios.

> But why not keep just one code (in src and include) and link
> to modules via preprocessor macros?
> 
> for example you could have
>    #define MP_ASMI_H ../../modules/.../asmi.h
> in build.h
> 
> and even for .cpp modules... a "stub file" for example
> es_stub.cpp
> containing just a
>    #include ES_MODULE_CPP (or h file
> 
> This could make your dynamic build happy, and would make my dirty static 
> build
> also happy... :)

Eeeh. I gotta say, this doesn't give me good feelings. :) However
several projects including Monotone are using various custom
configurations and in-tree builds these days and I'd like to make life
easier for those people if I can... I'll give it some thought.

> (actually I have a hand made build.h for all the configurations I care of)
> 
> My "dream" would be:
> - creation of "build.{architecture}.h" at configure time with all the macros
> - creation of build.h which includes "build.{architecture}.h"

Here's where my thinking on this is right now:

Add a --build-dir=<dir> command which puts everything that currently
goes into build/ into <dir> (defaulting to build/; I'll just use build
to refer to this directory from here). Store the configuration's
Makefile into build/, so that

./configure.pl gcc-linux-athlon --build-dir=build.athlon
./configure.pl gcc-solaris-sparc64 --build-dir=build.sparc
make -f build.athlon/Makefile
make -f build.sparc/Makefile

works without anything colliding.

Add a --local-config=<file> command, which, if given, sets up the
build.h header to also include this file (at the end, so it can
override any defaults).

Add a --build-name=<name> which simply defines a macro, something like
BOTAN_LOCAL_BUILD_NAME_IS_<name>, in build.h, so the local config file
can do checks like

#if defined(BOTAN_LOCAL_BUILD_NAME_IS_MYBUILD1) && defined(BOTAN_TARGET_ARCH_IS_IA32)
  // do something interesting
#elif defined(BOTAN_LOCAL_BUILD_NAME_IS_MYBUILD2)
  // do something else
#endif

Thoughts? Comments? Is there anything that you'd like to do that couldn't
be done with a system along these lines?

> 
> In my case, playing with build.h for esoteric builds would be... somewhat 
> easier.
> 
> Anyway, keep up the good work!
> 
> Luca. 

I try. :)

-Jack