Re: [Corelinux-develop] Frameworks

[Frank V. C. <fr...@co...>]

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