Giter Club home page Giter Club logo

bdemeta's People

Contributors

dharesign avatar frutiger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

bdemeta's Issues

Support for CXXFLAGS

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.

Support standalone packages

Add support for the various types of standalone packages:

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

Solve the issue of multiple kinds of targets

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.

Support plugins automatically loaded at runtime

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.

Support plugins available at link time

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.

Provide a -D flag specifying plugin type

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.

external_cflags prefix all other flags

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.

Support plugins explicitly loaded at runtime

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.

Handle spaces in roots

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

Distinguish between internal and external cflags

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.