Re: Exclude parts of a package

[Brian Drummond <brian3@shapes.demon.co.uk>]

On Sat, 07 Dec 2013 09:41:33 +0100, Felix Krause wrote:

> On 2013-12-06 21:27:53 +0000, Shark8 said:
> 
>> On Friday, December 6, 2013 1:48:43 PM UTC-7, Felix Krause wrote:
>>> 
>>> This is an interesting approach, but in my case, that would lead to
>>> massive code duplication 

>> Easy enough solution:
>> 1) Define everything [all of OpenGL, or at least portion-X (X : Types,
>> Functions, etc)] in one big package; for the current version (4.3,
>> IIRC).*
>> 2) Define version-packages which repeat the spec of the appropriate
>> functions and use renames in their body.
>> 3) Use the rename technique given by Brian.

>> Package Main_Stuff is
>>   Procedure Bob;  -- Introduced in v.1.
>>   Procedure Tim;  -- Introduced in v.1.2.
>>   Procedure Dave; -- Introduced in v.1.3.
>>   Procedure Bill; -- Introduced in v.1.3.

> But this would compile all implementation code regardless of the version
> the user requested. Let's say in your example, the actual implementation
> of Tim imports a C function. Even if I compile for version 1., the body
> of Tim will still be compiled, so the resulting binary would still link
> against the backend C function that is wrapped by Tim. So to execute the
> binary, I'd need C library version that supports Tim even though I don't
> use it. Or do I see this wrong?

As I understand it, they would all be compiled, but (unless the linker is 
completely brain-dead) only the ones you use would be linked.

So Tim's functions would be verified as syntactically correct (or you'd 
have to fix them!) even though your latest changes were only to upgrade 
v1. And I see that as a Good Thing since it reduces surprises for v1.2 
users of the package...

But Tim shouldn't be linked into the executable; therefore its dependency 
on the C library should also be eliminated. 
(This may require some linker options in the project file)

If the linker really can't do it, then I would 
(a) be surprised, and
(b) suggest refactoring the variants into different packages such that
v1_pkg is base_pkg,
v1.1_pkg is composed of base_pkg and v1.1_diff_pkg
and so on. 

- Brian