[Prev][Next][Index][Thread]

Re: A basic question: defining modules and libraries



Chris Double wrote:
> Eric Gouriou writes:
> 
> > I will never replace/upgrade those libraries individually, so having
> > them as DLL is useless to me (and I indeed would appreciate having
> > an option to compile those multiple projects into just one
> > executable, taking advantage of the added optimization
> > capabilities).
> 
> If you're not going to use the reuse the libraries or replace/upgrade
> them individually, why make them libraries? Why not just make them
> modules within a library? This would also take advantage of the added
> optimization capabilities.

 Indeed. And that's exactly why I want the module/library concepts to change,
because these "define libraries" group my modules in well separated sets of
functionality. If I were to put all the modules in one or even two libraries,
the result would be a mess.
 A typical example is this "Ego-Extensions" library. I want to keep it as a
library, as most of my projects import it. But I do not want to have it as a
DLL, as it is mostly a bunch of miscealleanous helper functions/macros that
should be inlined and/or dead-code eliminated in each of those projects.

 I gave a bit more thought to what I had proposed Sunday. I believe my proposal
was inadequate.
 I realize that the "define module" macro should not be extended. I believe
that since it is the level where language bindings are exported, modules
grouping modules (ie modules replacing the current libraries) should be forbidden.
(I do not want to have exports from, e.g., fun-o.IO and fun-o.IO.streams, like
in Java) 

 So am I happy with the current library/modules macros then ? Not completely.
There are two improvements I would like to see:
 A) a naming convention for libraries (maybe along the lines of Java)
    that would greatly reduce the chances of name collisions.
    (with _maybe_ the possibility/necessity of qualifying the imported modules
     names with the library name rather than the current renaming capabilities).

 B) A change in the current environments to move away from the idea of
    1 library  <=> 1 dll/shared library
    + I would like to be able to specify that 1 deliverable (be it an executable
      or a shared library) is made of multiple dylan libraries.
    + I also want to be able to specify what are the optimizations boundaries
      between deliverables (ie being able to specify the Loose/Tight boundaries,
      cf. FO).

 So from the 6/7 first-level libraries in my project, I want:
  + 1 .DLL made of 2 first-level libraries
  + 1 .EXE made of 5 first-level libraries
 And I would like the option to have the .EXE tight-bound to the .DLL (ie whenever the
 .DLL changes, I have to compile a new .EXE, but other .EXE can use the same .DLL).

 A related improvement may be to add versioning information in the "define library"
or in a new "define deliverable" top-level macro. With 2-level versioning,
tight-binding would require the same major and minor, and loose would only require
same major version.
 
> > Example: I have a library of miscellaneous language extensions I often use.
> > How do I name it, so that I can share it with the community without
> > risks ?
> 
> Can you export the modules without the ego- prefix and let the user of
> the library prefix them when using them if there is a clash? Something
> like:
> 
> define library my-library
>   [...]
>   export extensions, collections;
> end;
> 
> // user of library
> define library user-of-library
>   [...]
>   use my-library, prefix: "ego-";
> end;
> 
> define module a-module
>   [...];
>   use ego-extensions;
> end;

 Of course, but I still have the naming problem for the library
and I would prefer not to force my users (ie me for now :-) ) to go
trough the added trouble of renaming in 80% of my projects.
 I prefer to avoid problems for my users, ain't that sweet :-) ?

 Thanks for your comments and please criticize these new proposal.

 Eric

--
Eric Gouriou                             eric_gouriou@pobox.com
Follow-Ups: References: