[build2] How to detect and configure #define macros?
0joshua.olson1 at gmail.com
Mon Nov 6 23:29:01 UTC 2017
Thanks! That answers my last high-level build2 question for now. I'm gonna
see if I can make a JUCE package...
Off-topic now: I'll be looking at existing bpkgs to see how they handle
native libraries. Comment and question:
Comment: the src-url of https://cppget.org/libodb is broken (
https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree says 'invalid
Question: if package A depends on a semi-popular package B being installed
(e.g. libcurl, webkit, gtk headers on Linux), is it ever preferable for
package B to be a bpkg too?
On Mon, Nov 6, 2017 at 3:34 PM, Boris Kolpackov <boris at codesynthesis.com>
> Joshua Olson <0joshua.olson1 at gmail.com> writes:
> > To rephrase, can the build system extract macros from a project's source,
> > whether that means printing a list, making a config header. or something
> > else? Or is that out of scope for now?
> > I imagine one could look for #ifdef, #ifndef, and all-caps identifiers,
> > almost anything could be changed a la -D define flags so there's no
> > completely 'correct' way to do this.
> Yes, to handle this automatically will require quite a bit of magic.
> Generally, when porting an existing project to build2 we use the
> following procedure:
> 1. Identify how the existing build system communicates configuration
> to the source code. This is usually in the form of preprocessor
> macros either via a configuration files (e.g., config.h) and/or
> command line (e.g., -D options).
> 2. If necessary, narrow down the above set of macros to the actually
> used ones. This is necessary if the build system has a "kitchen
> sink" configuration file, like autotools-based projects often do.
> The way we achieve this is by grepping the project's source code
> for the use of each macro. We also use this as an opportunity to
> understand the exact meaning of each macro (which is not always
> evident from #1).
> 3. Appropriately define each macro when building with build2. This
> can done either via the command line (-D) from buildfiles or
> from a configuration file.
> In our work we try hard to come up with what we call a "static
> configuration file". It determines the configuration based on
> predefined macros for the target compiler/platform/standard
> library as opposed to, say, running some compilation tests
> like autoconf.
> In the future we also plan to support generating configuration
> files from .in templates.
> You can see some examples of real libraries that we have converted
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users