Menu
▾
▴
corelinux-develop
|
From: Frank V. C. <fr...@co...> - 2000-08-12 22:35:09
|
Ok, What I am do is added ex22 to build up the FunctionLibrary components, for testing, before integrating into libcorelinux. This enables me to incrementally test the abstractions in the core. The first thing I realized is that to enable dynamic loading I need to add the /usr/lib/libdl.a to the link line. Ipso facto it stands to reason that if I integrate this work to libcorelinux we end up with a dependency in the core we didn't normally have. What I'm getting at is I think that the IMPLEMENTATION of frameworks, in this case the FunctionalLibrary loader et.al. are probably really an example of the CoreLinux++ frameworks that are one of the goals of the project. Anyone? -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-08-20 14:35:41
|
Ok, some more thoughts. the clfw should really be limited to abstract framework bases. In otherwords, the FunctionLibrary loader implementation is a separate deliverable that requires libclfrmwrk and libcorelinux. That way the user has the ability, in the long term, in substituting which FunctionLibrary framework that they want to use. Or they can create their own. I didn't want to force frameworks down anyones throat and this seemed the most flexible. Thoughts? -- Frank V. Castellucci |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-21 21:23:55
|
> the clfw should really be limited to abstract framework bases. In > otherwords, the FunctionLibrary loader implementation is a separate > deliverable that requires libclfrmwrk and libcorelinux. > > That way the user has the ability, in the long term, in substituting > which FunctionLibrary framework that they want to use. Or they can > create their own. > > I didn't want to force frameworks down anyones throat and this seemed > the most flexible. Thoughts? so you want to move it again ? provide it as an example ? -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme Cambridge MA 02139 | d'honneur et de valeur, Tel (Office) : (00 1) (617) 253 0229 | sage et loyal. Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-08-21 21:53:39
|
Christophe Prud'homme wrote: > > > the clfw should really be limited to abstract framework bases. In > > otherwords, the FunctionLibrary loader implementation is a separate > > deliverable that requires libclfrmwrk and libcorelinux. > > > > That way the user has the ability, in the long term, in substituting > > which FunctionLibrary framework that they want to use. Or they can > > create their own. > > > > I didn't want to force frameworks down anyones throat and this seemed > > the most flexible. Thoughts? > so you want to move it again ? No, I don't want to move clfw or any of the abstractions (Library Load, Persist, etc.) that will go with it. When I create the FunctionLibraryLoad implementation, though, it should be as separate as clfw is to corelinux. > provide it as an example ? > > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme > Cambridge MA 02139 | d'honneur et de valeur, > Tel (Office) : (00 1) (617) 253 0229 | sage et loyal. > Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand > http://augustine.mit.edu/~prudhomm | > Following the hacker spirit > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-21 22:06:39
|
> No, I don't want to move clfw or any of the abstractions (Library Load, > Persist, etc.) that will go with it. > > When I create the FunctionLibraryLoad implementation, though, it should > be as separate as clfw is to corelinux. I see shouldn't be a problem to achieve that however they will be source-packaged in clfw but for the binary packages we can create separate packages for each component actually that's a good idea I think to modularise the frameworks as much as possible, it is unlikely that all components will be all used May be it is also interesting to have all the components merged also in one lib. So we would have - separates modules to provide lightweight services - one big lib to provide them all C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | A wise person makes his own Cambridge MA 02139 | decisions, Tel (Office) : (00 1) (617) 253 0229 | a weak one obeys public opinion. Fax (Office) : (00 1) (617) 258 8559 | -- Chinese proverb http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-13 01:27:49
|
> The first thing I realized is that to enable dynamic loading I need to
> add the /usr/lib/libdl.a to the link line. Ipso facto it stands to
> reason that if I integrate this work to libcorelinux we end up with a
> dependency in the core we didn't normally have.
libdl.a is standard, so requiring it is not such an issue
what we can do is update the corelinux configure.in to enable -ldl for the
examples
and update the AC_CHECK_CORELINUX for users who want to useconf+corelinux
and document for all other users
>
> What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
> this case the FunctionalLibrary loader et.al. are probably really an
> example of the CoreLinux++ frameworks that are one of the goals of the
> project.
>
> Anyone?
so what you say is that it is time to putthings into libframeworks?
if so why not!
in fact it is quite good to think that core(linux) really means it (that it
is a core library): that is to say that it doesn't extra libs
-ldl is not such a requirement but keeping corelinux as a standalone lib(a
part the c++ lib of course) is very good since dl features are needed only
for a one corelinux feature
My preference would be to not add -ldl as a requirement and so begin to
populate corelinux++ frameworks
C.
--
Christophe Prud'homme | So so is good, very good,
MIT, 77, Mass Ave, Rm 3-243 | very excellent good:
Cambridge MA 02139 | and yet it is not;
Tel (Office) : (00 1) (617) 253 0229 | it is but so so.
Fax (Office) : (00 1) (617) 258 8559 | -- William Shakespeare,
http://augustine.mit.edu/~prudhomm | "As You Like It"
Following the hacker spirit
|
|
From: Frank V. C. <fr...@co...> - 2000-08-13 02:15:36
|
Christophe Prud'homme wrote:
> [snip for irrelevance now that there is a quorum]
> >
> > What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
> > this case the FunctionalLibrary loader et.al. are probably really an
> > example of the CoreLinux++ frameworks that are one of the goals of the
> > project.
> >
> > Anyone?
> so what you say is that it is time to putthings into libframeworks?
> if so why not!
> in fact it is quite good to think that core(linux) really means it (that it
> is a core library): that is to say that it doesn't extra libs
>
> -ldl is not such a requirement but keeping corelinux as a standalone lib(a
> part the c++ lib of course) is very good since dl features are needed only
> for a one corelinux feature
>
> My preference would be to not add -ldl as a requirement and so begin to
> populate corelinux++ frameworks
Yes!
So it is reasonable for me to move the Library Load abstraction into a
framework itself, oui?
What we should now consider is organization of frameworks. I think
something like :
Until we come up with a Framework management framework (something to
discuss later), each of the sub-frameworks (Library Load, Persistence,
etc.) should exists as semi-independent libraries.
Maybe something along the lines of a java package metaphor. So:
where LibLoad = LibraryLoad (for example)
Main
====
clfrmwrk (vacous root)
clfrmwrk/LibLoad
clfrmwrk/LibLoad/admin
clfrmwrk/LibLoad/{etc}
Headers
=======
clfrmwrk/LibLoad/LibLoad
Sources
=======
clfrmwrk/LibLoad/src
clfrmwrk/LibLoad/src/LibLoad
clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
The key here is that we need the ability to release different versions
of different frameworks independent (with restrictions on later
dependencies) of each other.
Of course, your mastery on packaging will mean maybe using the root
(clfrmwrk) to automate that?
What do you think?
--
Frank V. Castellucci
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-13 03:06:53
|
> So it is reasonable for me to move the Library Load abstraction into a
> framework itself, oui?
Ok
>
> What we should now consider is organization of frameworks. I think
> something like :
>
> Until we come up with a Framework management framework (something to
> discuss later), each of the sub-frameworks (Library Load, Persistence,
> etc.) should exists as semi-independent libraries.
That's good
>
> Maybe something along the lines of a java package metaphor. So:
> where LibLoad = LibraryLoad (for example)
>
> Main
> ====
> clfrmwrk (vacous root)
> clfrmwrk/LibLoad
> clfrmwrk/LibLoad/admin
> clfrmwrk/LibLoad/{etc}
>
> Headers
> =======
> clfrmwrk/LibLoad/LibLoad
>
> Sources
> =======
> clfrmwrk/LibLoad/src
> clfrmwrk/LibLoad/src/LibLoad
> clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
Yes
My concern is also the installation of the corelinux framework
now we have -lcl++
corelinuxframework might be -lclfw++
or if we hace separate libs:
- loader : -lclfwll++
- persistence : -lclfwp++
the include files might go all in <prefix>/include/clfw
- <prefix>/include/clfw/LibLoad/*.hpp
- <prefix>/include/clfw/Persistence/*.hpp
and so on
so users would do:
#include<clfw/LibLoader.hpp>
or
#include<clfw/Presistence.hpp>
in LibLoader.hpp you include all necessary headers (like that
clfw/LibLoader/<whatever>.hpp) so that you need only to add
-I<prefix>/include
if prefix != /usr
and everything is defined within the namespace (for example) clfw::LibLoader
or clfw::Persistence
does it make sense?
is it somewhat related to what you have in mind?
>
> The key here is that we need the ability to release different versions
> of different frameworks independent (with restrictions on later
> dependencies) of each other.
yes
> What do you think?
see above :)
well I agree and ready to work
as for the release 0.4.26 I'll be online tomorrow afternoon
so we can tackle all the tasks before the release.
C.
--
Christophe Prud'homme |
MIT, 77, Mass Ave, Rm 3-243 | Virtue would go far if ...
Cambridge MA 02139 | vanity did not keep it company.
Tel (Office) : (00 1) (617) 253 0229 | -- La Rochefoucauld
Fax (Office) : (00 1) (617) 258 8559 |
http://augustine.mit.edu/~prudhomm |
Following the hacker spirit
|
|
From: Frank V. C. <fr...@co...> - 2000-08-13 03:37:49
|
Christophe Prud'homme wrote:
>
> > So it is reasonable for me to move the Library Load abstraction into a
> > framework itself, oui?
> Ok
> >
> > What we should now consider is organization of frameworks. I think
> > something like :
> >
> > Until we come up with a Framework management framework (something to
> > discuss later), each of the sub-frameworks (Library Load, Persistence,
> > etc.) should exists as semi-independent libraries.
> That's good
>
> >
> > Maybe something along the lines of a java package metaphor. So:
> > where LibLoad = LibraryLoad (for example)
> >
> > Main
> > ====
> > clfrmwrk (vacous root)
> > clfrmwrk/LibLoad
> > clfrmwrk/LibLoad/admin
> > clfrmwrk/LibLoad/{etc}
> >
> > Headers
> > =======
> > clfrmwrk/LibLoad/LibLoad
> >
> > Sources
> > =======
> > clfrmwrk/LibLoad/src
> > clfrmwrk/LibLoad/src/LibLoad
> > clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
> Yes
>
> My concern is also the installation of the corelinux framework
>
> now we have -lcl++
> corelinuxframework might be -lclfw++
> or if we hace separate libs:
> - loader : -lclfwll++
> - persistence : -lclfwp++
> the include files might go all in <prefix>/include/clfw
> - <prefix>/include/clfw/LibLoad/*.hpp
> - <prefix>/include/clfw/Persistence/*.hpp
> and so on
>
I was thinking that we have separate libs.
> so users would do:
>
> #include<clfw/LibLoader.hpp>
> or
> #include<clfw/Presistence.hpp>
>
> in LibLoader.hpp you include all necessary headers (like that
> clfw/LibLoader/<whatever>.hpp) so that you need only to add
> -I<prefix>/include
> if prefix != /usr
>
> and everything is defined within the namespace (for example) clfw::LibLoader
> or clfw::Persistence
>
> does it make sense?
> is it somewhat related to what you have in mind?
Yes, and yes. Just to be sure, if the directory starts to look like
this:
clfw
clfw/admin
clfw/clfw (where LibLoad.hpp, Persist.hpp as you suggest exist)
clfw/LibLoad (where the interface headers exist)
clfw/Persist
clfw/src
clfw/src/LibLoad
clfw/src/Persist
for example, and you won't have any problem producing either libclfw++,
or libclfwll++, or libclfwp++ on demand?
I have setup header includes in this way in the past, usually two files
(for example):
in LibLoad.hpp
//
// Base include
//
#include <corelinux/Common.hpp>
//
// Directory redirect header
//
#include <LibLoad.h>
<EOF>
and in LibLoad.h
#define Incl_Library <LibLoad/Library.hpp>
#define Incl_FunctionLibrary <LibLoad/FunctionLibrary.hpp>
<EOF>
So the includes in source start to look like this:
#include <LibLoad.hpp>
#include Incl_FunctionLibrary
>
> >
> > The key here is that we need the ability to release different versions
> > of different frameworks independent (with restrictions on later
> > dependencies) of each other.
> yes
>
> > What do you think?
> see above :)
>
> well I agree and ready to work
Well, I can setup the initial stuff (and get Library et.al. moved
first), once we are clear on the directory structures.
> as for the release 0.4.26 I'll be online tomorrow afternoon
> so we can tackle all the tasks before the release.
As I will be pulling the LibLoad abstractions out, it would seem that
the major changes for release are:
DEB
RPM
Class Reference Documentation
Version (0.0.0) changes
did I miss anything? Sound right?
--
Frank V. Castellucci
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-14 00:56:26
|
Ok the debian packages are done I am also ucvs-pdating a minor change I made for this packaging > As I will be pulling the LibLoad abstractions out, it would seem that > the major changes for release are: > DEB Done > RPM your job? > Class Reference Documentation what do you mean? > Version (0.0.0) changes ?? C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | The Second Law of Thermodynamics: Cambridge MA 02139 | If you think things are in a mess Tel (Office) : (00 1) (617) 253 0229 | now, just wait! Fax (Office) : (00 1) (617) 258 8559 | -- Jim Warner http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-08-14 01:00:20
|
Christophe Prud'homme wrote: > > Ok the debian packages are done > I am also ucvs-pdating a minor change I made for this packaging > > > As I will be pulling the LibLoad abstractions out, it would seem that > > the major changes for release are: > > > DEB > Done > > RPM > your job? Yes > > Class Reference Documentation > what do you mean? Now that I have doxygen 1.2.0 it creates the PDF and PS files, no need for you to do this. The 1.2.1 has your changes (your name was in the credits!!!). I will be creating the Class Reference documentation rpm at this point. > > > Version (0.0.0) changes I assume that you made not of the changes in ChangeLog or README concerning the new version numbering? -- Frank V. Castellucci |
