[build2] How to detect and configure #define macros?

Joshua Olson 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
request')

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>
wrote:

> 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,
> but
> > 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
> here:
>
> https://git.build2.org/cgit/packaging/
>
> Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20171106/8cf66284/attachment.html>


More information about the users mailing list