From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!news.astraweb.com!border6.a.newsrouter.astraweb.com!cyclone03.ams2.highwinds-media.com!news.highwinds-media.com!voer-me.highwinds-media.com!peer03.am1!peering.am1!npeersf04.am4!fx10.fr7.POSTED!not-for-mail From: Brian Drummond Subject: Re: Exclude parts of a package Newsgroups: comp.lang.ada References: <52a0de7e$0$23162$2c885b36@post.eweka.nl> <2Kiou.15508$bz3.2509@fx24.fr7> <52a2382a$0$7939$2c885b36@post.eweka.nl> <4152aa2a-ad91-4cac-a5ad-30f6e7544647@googlegroups.com> <52a2df3d$0$24107$2c885b36@post.eweka.nl> User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 62.49.20.82 X-Complaints-To: abuse@demon.net X-Trace: 1386417316 62.49.20.82 (Sat, 07 Dec 2013 11:55:16 UTC) NNTP-Posting-Date: Sat, 07 Dec 2013 11:55:16 UTC Date: Sat, 07 Dec 2013 11:55:16 GMT X-Received-Body-CRC: 2127854248 X-Received-Bytes: 3103 Xref: news.eternal-september.org comp.lang.ada:17895 Date: 2013-12-07T11:55:16+00:00 List-Id: 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