Required to be able to handle plugins statically or structurally linked plugins (.a or a .so bound by the linker as opposed to dlopen/LoadLibrary). The difference between internal and external cflags is that the internal is needed when building the item (plugin or library) while the external are needed when compiling dependent items, such as an executable that includes a structural plugin. But this is not just for plugins, but for all dependencies that are "insulated" by the depended item, therefore their cflags are not needed when building the dependent item. We already have such a library that needs an extra flag option -- because it is built upon a C library that (ab)uses the C preprocessor on ways that look cute first, and when you realize what happens it is too late for you (to regain your sanity -- imagine .c files including .c files and using MACROS to rewrite them).

We may just introduce a local .bdemetarc for the above kind of C code that touches itself in ways no code should do in polite company, because those are "static". However such tricks does not save us from the headaches of plugins: where we have 2 sets of dependencies. One is for building the plugin and the other is for using the plugin. My plugin may need the mabi_mandarin implementation, but the whole point of the plugin (which should rather be called "companion"...) is to not makes the executable dependent on any of the plugin's specifics. Shared-library plugins will contain all their dependencies, while static ones will require us to link them into the final executable. However neither will require us to add any flag dependencies to the building of the executable.

Current bdemeta does not support the distinction between inner and outer dependencies. We may decide that for plugins we will treat every dependency as inner, and users must declare the dependencies explicitly that are necessary for using the plugin (such as dependencies for some protocols); but even in that case, internally, bdemeta will need to have two kinds of cflags: the this-is-what-I-need-to-build-the-thing and the this-is-what-is-passed-on-to-my-dependents.

I suggest that we call such dependencies _insulated dependencies_ (note that it is not insulted) as they are called in Lakosia; as it all so clearly describes what our plugins do: insulate our main program from the need to know about every subsystem.

Sorry for being so verbose.

If I have a .bdemetarc file which looks like:

{
    "roots": [
        "/some/path/containing/A"
    ],
    "units": {
        "#universal": {
            "external_cflags": [
                "-I/some/other/path/containing/A_headers"
            ]
        }
    }
}

Then the resulting ninja flags looks like:

flags = -I/some/other/path/containing/A_headers -I/some/path/containing/A/package

Which means it picks up the out-of-date versions of the headers. Really the #universal stuff should be sorted to the back, as I think the README even suggests:

The optionally specified <univ_cflag> is appended when generating cflags for any component.

Is there a better way to do this? I have not found any settings with ninja that might control this. I do notice that just running $ touch build.ninja does not cause everything to be invalidated.

When plugins are being built, they may be built in one of three modes (see #12, #13, and #14). Provide a -D rule with well-known values for code being compiled under the plugin so that it can be aware of which mode it is being compiled in.

This issue was originally reported in #7.

A plugin automatically loaded at runtime is a shared library that is provided as a link-time dependency of some other code. This other code may then freely use symbols from the plugin as long the name of the exported symbols are known (e.g. through header files).

These shared libraries would have to be deployed together with the code using them in order to avoid mismatched symbol names and symbol signatures/behaviours. This stands in contrast to #14 where the resulting binary contains all the requisite dependencies.

This would implement option (2) from #7.

A plugin available at link time is a static library that is provided as a link-time dependency of some other code. This other code may then freely use functions from the library as long the name of the exported symbols are known (e.g. through header files).

The code may also then be deployed without any further requirements. This stands in contrast to #13, which requires the using code and the shared library to be deployed together.

This would implement option (3) from #7.

When I am making a plugin I may have 3 kinds of different ways of building it.

1. A shared library (that I am going to open with dlopen/LoadLibrary).
2. A shared library that I link in structurally, just like the C runtime is linked in.
3. A static library that I fully link in, as if linking in all of its objects.

Side note: These 3 might require differences in the source, which we may have to contain with #if ugliness (unless we can hide the differences in components -- not enough experiences to say which will be true). We assume the "worst case" for the build system: we build all 3 variant from the same source code. In which case we will need:

1. A way to say (with the executable) not only what plugins we want to build with it, but which variant of the 3
2. In the plugin sources we would like to know what are we building, so a adding some -Dtarget-type-thing sounds like a good idea
3. We probably don't want to build all variants of a plugin, just what is asked for, when building for production.
4. We don't want to build all variants of plugins even when testing, because not all variants may be supported; so we need some sort of capabilities info as well.

The problem is that, at the moment, as a programmer, I cannot have a static and a dynamic plugin, unless I edit the source code of bdemeta; as the tool has no concept of multiple different outputs. So plugins (all plugins) are either static or dynamic. So to step closer to a solution we need to be able to specify for each element (group, plugin) what kind of targets do they support and their users (the dependent executable) should be able to specify what flavor do they want. (This is somewhat similar to thread-aware/single-threaded variants. We don't need groups ending up being shared libraries right now, but BDE is already doing that for Windows.) Whatever way we do these in the metafiles, it has to be the same how BDE wants to do it -- assuming they have one.

Currently, building of tests will stop and fail if there is a component that has no test driver; we should just skip them instead.

A plugin explicitly loaded at runtime is a dynamically loadable module that exports some set of symbols. Other code may then load and use those symbols using operating system provided facilities (e.g. dlopen or LoadLibrary) if it knows the names and types of the exported symbols.

These dynamically loadable modules would have to be deployed together with the code using them in order to avoid mismatched symbol names and symbol signatures/behaviours.

This would implement option (1) from #7.

This causes ninja to force a rebuild as it detects the command-line to generate some output has changed.

The cflags variables are used for both C and C++ files, which prevents specifying options which are relevant to C++ only, e.g., -std=c++03. We may want to add equivalent cxxflags variables.

Add support for the various types of standalone packages:

adapters/
  a_foo/
applications/
  foo/
groups/
  s_foo/

Currently the path used in a root cannot contain a space, at least not if done via the .bdemetarc file.

Currently bdemeta assumes that source files within standard packages are all cpp files. It would be nice if it could support m and mm files as well.