search

frutiger / bdemeta

Build and test BDE-style code
8 stars 8 forks source link

Solve the issue of multiple kinds of targets #7

Closed cppguru closed 9 years ago

cppguru commented 10 years ago

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.

frutiger commented 9 years ago

This issue will be resolved (at least partially) when I attempt to allow plugins as a first-class citizen of bdemeta.

frutiger commented 9 years ago

As a first cut, I am looking at how to implement option 1:

  1. A shared library (that I am going to open with dlopen/LoadLibrary).
frutiger commented 9 years ago

@cppguru I have broken up the original issue into 4 new issues: #12, #13, #14 and #15. I hope you don't mind if I close this issue. If you see something that you have requested that is not covered in those other issues but is related, then please update them. If it seems somewhat unrelated, please create a new issue.

cppguru commented 9 years ago

If you do not want to bother with dlopen/LoadLibrary you may just link it in as usual. Don't waste your time on the pligin infrastructure, I am supposed to implement that. I think we should not have competing ones. Talk to Brock if you think we should.

On Mon, Feb 2, 2015 at 2:52 AM, Masud Rahman notifications@github.com wrote:

Closed #7 https://github.com/frutiger/bdemeta/issues/7.

— Reply to this email directly or view it on GitHub https://github.com/frutiger/bdemeta/issues/7#event-228326421.