<div dir="ltr">Thanks! That answers my last high-level build2 question for now. I'm gonna see if I can make a JUCE package... <div> </div><div>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 <a href="https://cppget.org/libodb" target="_blank">https://cppget.org/libodb</a> is broken (<a href="https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree" target="_blank">https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree</a> says 'invalid request') </div><div>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?</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Nov 6, 2017 at 3:34 PM, Boris Kolpackov <<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Joshua Olson <<a href="mailto:0joshua.olson1@gmail.com" target="_blank">0joshua.olson1@gmail.com</a>> 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: <a href="https://git.build2.org/cgit/packaging/" rel="noreferrer" target="_blank">https://git.build2.org/cgit/packaging/</a> Boris </blockquote></div> </div></div>