frutiger / bdemeta Goto Github PK
View Code? Open in Web Editor NEWBuild and test BDE-style code
Build and test BDE-style code
Currently, building of tests will stop and fail if there is a component that has no test driver; we should just skip them instead.
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.
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.
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.
Add support for the various types of standalone packages:
adapters/
a_foo/
applications/
foo/
groups/
s_foo/
When I am making a plugin I may have 3 kinds of different ways of building it.
dlopen
/LoadLibrary
).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:
-D
target-type-thing sounds like a good ideaThe 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.
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.
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.
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.
Currently the path used in a root cannot contain a space, at least not if done via the .bdemetarc
file.
This causes ninja to force a rebuild as it detects the command-line to generate some output has changed.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.