[botan-devel] build system feature request

Jack Lloyd lloyd at randombit.net
Tue Jan 29 13:06:15 EST 2013

I like this in concept.

When I rewrite the build script into python, one consideration was
making it possible for outside scripts to import botan's configure.py
and run the configuration in some specialized way. However I'm not
sure I want anything that is in configure.py right now to be a stable
API that I can't break, either. So a more limited interface that is
easier to keep for extended time, especially one that handles all the
easy cases where someone would want to hook into the build, seems
quite useful.

However it is hard for me to see how the information in this proposal
would allow actually compiling the list of sources, missing basic
things like the target compiler and etc. So while it might work for
your special case it doesn't seem too good beyond that.

An approach I think would be more promising in terms of being widely
applictable is cleaning up some of the data structures and pretty
printing them to a file. BuildConfigurationInformation already
captures most of what you are looking for (and much more), that plus
the selected target information, list of code modules, etc could all
be written as literals for import.

Ideally this file could even be reimported into configure.py to cause
it to exactly replicate that build configuration.

On Sun, Jan 27, 2013 at 01:40:49AM +1100, john skaller wrote:
> Ok, I've had a look at the build system and I'd like to try
> for a specification of a feature request.
> 1. Command option:
> python configure.py --pyconfig-data=filename.py .....
> This option specifies that the configure.py script will write some data,
> as specified below, into filename.py.
> 2. filename.py format
> class botan_data:
> 	"""
> 	list of strings of files to be made available for use of library
> 	"""
> 	def get_public_include_files()
> 	"""
> 	list of strings of dirs required to compile the library and tools,
> 	i.e. to use after -I switches
> 	"""
> 	def get_lib_include_dirs()
> 	"""
> 	list of source files to be compiled to make the library
> 	"""
> 	def get_lib_sources()
> 	"""
> 	list of source files to be compiled into executable tools
> 	"""
> 	def get_tool_sources()
> The format is chosen so the generated file and be imported.
> ============================================================
> Use case: Felix uses fbuild to build things. It is desirable
> to embed core third party libraries directly in the build so as
> to relieve customers of the burden of configuration.
> Felix already embeds Google RE2, Tre, sqlite3.
> Felix uses a specific method to build things.
> We define a command for building
> 	compiling static link library code
> 	compiling dynamic link library code
> 	linking static libraries
> 	linking dynamic libraries
> 	compiling executables
> 	linking executables
> and the compiler switches are "the same" for all code in the system
> for each class. Also, libraries are named in a fixed way: felix built
> libraries get called something like:
> 	libflx_libname_static.a
> 	libflx_libname_dynamic.so
> on unix for example. The "flx_" is to prevent a clash with the same
> library available externally. The "static" or "dynamic" is to prevent
> stupid linkers like ld finding the wrong kind of library.
> There's one more hassle: setting BOTAN_DLL. New email for that one :)
> --
> john skaller
> skaller at users.sourceforge.net
> http://felix-lang.org
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://lists.randombit.net/mailman/listinfo/botan-devel

More information about the botan-devel mailing list