Menu
▾
▴
corelinux-develop — Developer centric mail list for CoreLinux++
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(144) |
Aug
(209) |
Sep
(117) |
Oct
(44) |
Nov
(41) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(64) |
Mar
(25) |
Apr
(35) |
May
(29) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(12) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(7) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
(9) |
Jun
(11) |
Jul
(9) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
(9) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(16) |
Sep
(7) |
Oct
(8) |
Nov
(8) |
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
(7) |
Mar
(27) |
Apr
(26) |
May
(28) |
Jun
(17) |
Jul
(38) |
Aug
(13) |
Sep
(17) |
Oct
(12) |
Nov
(37) |
Dec
(51) |
| 2009 |
Jan
(41) |
Feb
(19) |
Mar
(30) |
Apr
(43) |
May
(138) |
Jun
(111) |
Jul
(76) |
Aug
(27) |
Sep
(28) |
Oct
(33) |
Nov
(11) |
Dec
(18) |
| 2010 |
Jan
(3) |
Feb
(5) |
Mar
(40) |
Apr
(51) |
May
(74) |
Jun
(76) |
Jul
(46) |
Aug
(41) |
Sep
(26) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christophe Prud'h. <pru...@MI...> - 2001-09-06 23:55:32
|
* Ian Crawford [Thursday 06 September 2001 10:45 am ] :
> Now, I'm completely unfamiliar with CoreLinux++, so I might be out o=
f
> line posting here. I apologize in advance if this is the case.
Not at all, the point of this list is to share ideas on analysis/design/i=
mplementation
The problem with smart pointers is that there are so many ways to do it =
and to use them.
IMHO depending on the type of application/usage, "different" policies sho=
uld/could be used
so when it comes to use smart pointers in multithreading codes, then the =
multithreaded version
would be used whereas the singlethreaded one would be used in general. Me=
mory management is also=20
a policy and can be done in several ways. Checking correctness/nonnullnes=
s is also a policy: whether you
want or not to check to validity of the pointee at any time.
In this respect the work of Andrei Alexandrescu(Modern C++ design publish=
ed by Addison Wesley ) is
very interesting and shows how smart pointers can be implemented using te=
mplates and policies.
Basically the smart pointer class look like this (excerpt from the book)
template
<
typename T,
template <class> class OwnershipPolicy =3D RefCounted,
class ConversionPolicy =3D DisallowConversion,
template <class> class CheckingPolicy =3D AssertCheck,
template <class> class StoragePolicy =3D DefaultSPStorage
>
class SmartPtr;
The various policies are orthogonal and can be changed easily. policies a=
re very small classes
which customized the behaviour of the SmartPtr.
I strongly suggest the reading of this book in general and the chapter on=
smart pointer in particular.
I was waiting Frank to come back and discuss about this design.
see ya
C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem -- http://kfem.sourceforge.net
|
|
From: Ryan M. <rya...@te...> - 2001-09-06 20:23:19
|
On September 6, 2001 01:01 pm, you wrote:
>
> Message: 1
> Date: Thu, 6 Sep 2001 10:45:26 -0400 (EDT)
> From: Ian Crawford <co...@st...>
> To: <cor...@li...>
> Subject: [Corelinux-develop] Smart pointers.
>
> Now, I'm completely unfamiliar with CoreLinux++, so I might be out of line
> posting here. I apologize in advance if this is the case.
>
> Anyway, I just read the SmartPointer draft. The sample code in the Cons
> section left me a little curious. I use a homegrown reference counting
> system in my own software with an interface that, IMHO, is a bit more
> civilised than the one proposed in the SmartPointer draft.
>
> I'll try explaining first. If I leave everyone wondering, I'll post code
> later.
>
> My object class has a flag (specified in the constructor) that indicated
> whether the object was allocated on the head and, thus, needs to delete
> itself when it's reference count hits 0. On top of that, it has a
> reference count and a mutex (since, AFAIK, modifying the reference count
> is non-reentrant).
>
> Then, I have an object_ref<T> template. The less obvious, more
> interesting parts of this class are operator*, operator->, and operator T*
> (i.e., an automatic cast to type <T*>). So, given the declarations:
>
> class Point : public object {
> public:
> Point( bool dynamic ) : object(dynamic) { }
>
> void Draw();
> // ...
> };
>
> typedef object_ref<Point> Point_ref;
>
> Point* p = new Point;
> Point_ref pref = new Point(true);
>
> The following statements are equivalent (because of operator* and
> operator-> in object_Ref):
>
> p->Draw();
> pref->Draw();
> (*p).Draw();
> (*pref).Draw();
>
> And so are these (because of operator T*):
>
> if( p ) p->Draw();
> if( pref ) pref->Draw();
>
> Now, I don't follow the iterator examples SmartPointer draft, but using
> STL containers, I often do things like:
>
> typedef std::list<Point_ref> Point_ref_list;
> typedef Point_ref_list::iterator Point_ref_list_i;
>
> Point_ref_list pl;
>
> pl.push_back( new Point(true) );
> // etc.
>
> for( Point_ref_list_i i = pl.begin(); i != pl.end(); ++i )
> (*i)->Draw();
>
> In all these above examples, Point is a managed object (since it inherits
> from object) and will be deleted when it's reference count reaches 0.
> object_ref references/unreferences the object on construction/destruction
> preventing the object from leaking.
>
> Well, I thought this might inspire the SmartPointer development in
> CoreLinux++. I hope this is on topic.
>
> For the sake of discussion, I'm thinking about changing the self-deletion
> part of my object class to a system similar to Java's garbage collection.
> A registry could track all dynamically allocated objects and a low
> priority thread could pass over the collection periodically and delete any
> whose reference counts are zero (i.e., collect the garbage). The
> advantage I could see of a system like this is that object destructors
> wouldn't necessarily take time from the main thread (if this is
> important... I'm not sure it is). Disadvantages being that you'd be
> wasting memory on the short term, you would need additional logic to
> prevent an object from being destroyed after construction but before it is
> first referenced, and it would take time (not a lot, but probably more
> than I'm willing to spend on it right now) to implement. But it's
> certainly worth considering for an object management system in
> CoreLinux++.
>
> BTW, has any of that SmartPointer code actually been written?
>
> Ian.
Your not out of line at all. In fact Im glad youve taken the time to share
your views. Im a compsci student in canada, and while Im not actually that
helpful around here, I am interested in these sorts of design issues.
You should definately talk with Frank about your ideas. Hes a nice guy, but I
think hes on vacation, since he has repsonded to my last email.
On a side note, I find it intersting that alot of what is being done to
improve C++ is already implemented in C#. I cant wait until Ximian is done
Mono...
|
|
From: Ian C. <co...@st...> - 2001-09-06 14:38:17
|
Now, I'm completely unfamiliar with CoreLinux++, so I might be out of line
posting here. I apologize in advance if this is the case.
Anyway, I just read the SmartPointer draft. The sample code in the Cons
section left me a little curious. I use a homegrown reference counting
system in my own software with an interface that, IMHO, is a bit more
civilised than the one proposed in the SmartPointer draft.
I'll try explaining first. If I leave everyone wondering, I'll post code
later.
My object class has a flag (specified in the constructor) that indicated
whether the object was allocated on the head and, thus, needs to delete
itself when it's reference count hits 0. On top of that, it has a
reference count and a mutex (since, AFAIK, modifying the reference count
is non-reentrant).
Then, I have an object_ref<T> template. The less obvious, more
interesting parts of this class are operator*, operator->, and operator T*
(i.e., an automatic cast to type <T*>). So, given the declarations:
class Point : public object {
public:
Point( bool dynamic ) : object(dynamic) { }
void Draw();
// ...
};
typedef object_ref<Point> Point_ref;
Point* p = new Point;
Point_ref pref = new Point(true);
The following statements are equivalent (because of operator* and
operator-> in object_Ref):
p->Draw();
pref->Draw();
(*p).Draw();
(*pref).Draw();
And so are these (because of operator T*):
if( p ) p->Draw();
if( pref ) pref->Draw();
Now, I don't follow the iterator examples SmartPointer draft, but using
STL containers, I often do things like:
typedef std::list<Point_ref> Point_ref_list;
typedef Point_ref_list::iterator Point_ref_list_i;
Point_ref_list pl;
pl.push_back( new Point(true) );
// etc.
for( Point_ref_list_i i = pl.begin(); i != pl.end(); ++i )
(*i)->Draw();
In all these above examples, Point is a managed object (since it inherits
from object) and will be deleted when it's reference count reaches 0.
object_ref references/unreferences the object on construction/destruction
preventing the object from leaking.
Well, I thought this might inspire the SmartPointer development in
CoreLinux++. I hope this is on topic.
For the sake of discussion, I'm thinking about changing the self-deletion
part of my object class to a system similar to Java's garbage collection.
A registry could track all dynamically allocated objects and a low
priority thread could pass over the collection periodically and delete any
whose reference counts are zero (i.e., collect the garbage). The
advantage I could see of a system like this is that object destructors
wouldn't necessarily take time from the main thread (if this is
important... I'm not sure it is). Disadvantages being that you'd be
wasting memory on the short term, you would need additional logic to
prevent an object from being destroyed after construction but before it is
first referenced, and it would take time (not a lot, but probably more
than I'm willing to spend on it right now) to implement. But it's
certainly worth considering for an object management system in
CoreLinux++.
BTW, has any of that SmartPointer code actually been written?
Ian.
--
-----------------------------
http://www.stasis.org/~codic/
|
|
From: Frank V. C. <fr...@co...> - 2001-07-14 09:48:25
|
Christophe, I was out all week, vacation is for the spoiled <grin> Have fun and enjoy! Christophe Prud'homme wrote: > > Hey Frank > I leave for a two weeks vacation in France > I have my new laptop and I hope to have time to make progress on the meta compiler > > best regards > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/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...> - 2001-07-11 14:20:58
|
Hey Frank I leave for a two weeks vacation in France I have my new laptop and I hope to have time to make progress on the meta= compiler=20 best regards C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Frank V. C. <fr...@co...> - 2001-07-07 15:24:43
|
Christophe, Feel free, then, to change the make macro to include/exclude files during the build. Please do NOT put any conditional tests into the source files, if it comes to that let me know. -- 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...> - 2001-07-06 15:06:25
|
grrrr I shoud read my emails before sending them=20
* Christophe Prud'homme [Vendredi 06 Juillet 2001 10:48 AM ] :
> * Frank V. Castellucci [Vendredi 06 Juillet 2001 06:24 AM ] :
> > I'm thinking.
> >
> > Isn't there a Linux OS emulation library for windows or something=
?
> > I'd hate to mod any code (there is a bunch of the Guard usage
> > throughout) or remove any for that matter.
>
> cygwin is a POSIX Layer over cygwin
^ Windows of course
C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem -- http://kfem.sourceforge.net
|
|
From: Christophe Prud'h. <pru...@MI...> - 2001-07-06 14:57:05
|
* Frank V. Castellucci [Vendredi 06 Juillet 2001 06:24 AM ] : > I'm thinking. > > Isn't there a Linux OS emulation library for windows or something? I'= d > hate to mod any code (there is a bunch of the Guard usage throughout)= or > remove any for that matter. cygwin is a POSIX Layer over cygwin it supports signals, pthread and other POSIX stuff so far this is working for me (however corelinux thread is using none POS= IX stuff) the idea is not to remove/change code but to disable the compilation of s= ome files=20 under cygwin . this is done using conditional in automake=20 This way the code is safe :) C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Frank V. C. <fr...@co...> - 2001-07-06 10:20:36
|
I'm thinking. Isn't there a Linux OS emulation library for windows or something? I'd hate to mod any code (there is a bunch of the Guard usage throughout) or remove any for that matter. Christophe Prud'homme wrote: > > Hi all, > > I know that Corelinux is for linux > and there will be no effort to port on other platforms > unfortuantely some of my codes depend on corelinux now :) > and cygwin is one of my platform. So I had to take some steps > > basically the ppatern are Ok under cygwin > only problems were sytem related: memory/sempahore/thread > I removed this stuff and I got Corelinux working under cygwin > > Frank do you mind if I incorporate some cygwin stuff? > right now that would be : not compiling the files related to the > system above > > what do you think? > > regards > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/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...> - 2001-07-06 00:06:26
|
Hi all, I know that Corelinux is for linux and there will be no effort to port on other platforms unfortuantely some of my codes depend on corelinux now :) and cygwin is one of my platform. So I had to take some steps basically the ppatern are Ok under cygwin only problems were sytem related: memory/sempahore/thread I removed this stuff and I got Corelinux working under cygwin Frank do you mind if I incorporate some cygwin stuff? right now that would be : not compiling the files related to the=20 system above what do you think? regards C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-06-20 14:11:36
|
Hi all, debian packages for clfw 0.2.8 are out as always add this in your apt/source.list deb http://corelinux.sourceforge.net/debian ./ deb-src http://corelinux.sourceforge.net/debian ./ Note that I am officially a debian developer, I hope to make=20 corelinux available for the debian masses :) Frank: you can get the debian packages in /home/groups/c/co/corelinux/htd= ocs/debian best regards C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-06-18 17:44:51
|
* Frank V. Castellucci [Dimanche 17 Juin 2001 06:38 am ] : > Christophe, > > About a week ago you mentioned that you were going to build libclfw++ > 0.2.8 debians. I'll continue to keep an eye on the directory where yo= u > have been storing them, but I am refraining from tag label or change = the > source base until you done the build. > > Let me know what to do, thanks grr I have to change the email address I gave for corelinux ML this one keeps receiving tons of spam and I don't check it very often I was in conferences last week, I didn't have time :( Ok now I received corelinux emails at MIT good! I'll do the debs today, it was on my TODO List regards C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Frank V. C. <fr...@co...> - 2001-06-17 10:34:06
|
Christophe, About a week ago you mentioned that you were going to build libclfw++ 0.2.8 debians. I'll continue to keep an eye on the directory where you have been storing them, but I am refraining from tag label or change the source base until you done the build. Let me know what to do, thanks -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2001-06-04 10:51:06
|
This release of the library contains refinements to MetaClass resolution, as well as providing the ability for applications to identify the Schema class to use in SchemaCatalog::createEntry. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2001-06-04 09:48:32
|
YES! Man, sorry, I knew I forgot to post the 0.2.8 notice somewhere :) Had to rush to take my Father-in-law out for his birthday. PS: Don't ever get married :) Christophe Prud'homme wrote: > > Hi frank > > shall I make the debs? > > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/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...> - 2001-06-03 23:41:38
|
Hi frank shall I make the debs? C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-05-16 17:59:01
|
Le Mardi 15 Mai 2001 08:06 pm, vous avez =E9crit : > Once again you make me laugh. Have at it! hum I am not sure I understand why :) C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Frank V. C. <fr...@co...> - 2001-05-16 00:06:07
|
Heh. No, I meant for what are we using it for? Christophe Prud'homme wrote: > > Le Mardi 15 Mai 2001 05:10 pm, vous avez écrit : > > Before we sign off on the xml stuff, I had wanted to discuss what > > exactley it does? > here is the web site: > http://xmlsoft.org/ > note that it doesn't depend on GNOME(gnome-xml is just the former name) > > regards > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/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: Frank V. C. <fr...@co...> - 2001-05-16 00:03:08
|
Once again you make me laugh. Have at it! Christophe Prud'homme wrote: > > Le Mardi 15 Mai 2001 05:08 pm, vous avez écrit : > > As long as when we do the tarball source that each has a copy being > > included where neccessary > the admin dir will be always in each module > BUT in CVS it is shared by all modules > > you would have something like > > admin > corelinux corelinux &admin > clfw clfw &admin > clfll &admin > > cvs is really powerful isn't it > one module can be a set of other modules > see CVSROOT/modules file > > I'll do the change > > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/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...> - 2001-05-15 21:35:34
|
Le Mardi 15 Mai 2001 05:10 pm, vous avez =E9crit : > Before we sign off on the xml stuff, I had wanted to discuss what > exactley it does? here is the web site: http://xmlsoft.org/ note that it doesn't depend on GNOME(gnome-xml is just the former name) regards C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-05-15 21:30:44
|
Le Mardi 15 Mai 2001 05:08 pm, vous avez =E9crit : > As long as when we do the tarball source that each has a copy being > included where neccessary the admin dir will be always in each module BUT in CVS it is shared by all modules you would have something like admin corelinux corelinux &admin clfw clfw &admin clfll &admin cvs is really powerful isn't it one module can be a set of other modules see CVSROOT/modules file I'll do the change C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Frank V. C. <fr...@co...> - 2001-05-15 21:07:59
|
Before we sign off on the xml stuff, I had wanted to discuss what exactley it does? I had assumed that you back burnered the whole idea because of school obligations for awhile. FC Christophe Prud'homme wrote: > Hi > > I ran into some problems recently while creating the .debs > I realized that some stuff were broken(the .la files in the .debs packages for example) > > * short term(today) > ** I will update libtool (config.*, ltmain.sh) > ** rebuild all debs > > * medium term > ** work on the admin/ as soon as I have the green light > ** incorporate the xml stuff > ** metaclass/idl generator vased on xml description > > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/listinfo/corelinux-develop |
|
From: Frank V. C. <fr...@co...> - 2001-05-15 21:05:49
|
As long as when we do the tarball source that each has a copy being included where neccessary Christophe Prud'homme wrote: > Hi all, > > it would be good for me if the admin/ dir was shared by all modules > corelinux > clfw > clfll > I would like to do that > have I the green light? > > TODO: > > * configure modules in CVSROOT > * add Makefile.common > * update libtool to newest version > * everybody will have to recheckout all modules > > GAIN: > > * make sure that every modules is up to date regarding the m4 macros and config files > * do a lot of common work in the admin dir --> reduce maintainer work > * for last item create a Makefile.common > * add a cvs-clean rule so that we are sure that the module will be cleaned up correctly > * ease the packaging for me :) > * ... more minor stuff > > comments? thoughts? > C. > -- > Christophe Prud'homme > OOA and OOD for Linux > CoreLinux -- http://corelinux.sourceforge.net > Finite Element Method Codes > KFem -- http://kfem.sourceforge.net > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/lists/listinfo/corelinux-develop |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-05-15 19:01:04
|
Hi all, I just rebuilt all corelinux debian packages * fix a problem with .la files and libtool=20 * fix shared lib .so location as always you can get them by adding the following line in your /etc/apt/= sources.list deb http://corelinux.sourceforge.net/debian ./ deb-src http://corelinux.sourceforge.net/debian ./ best regards and enjoy! C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-05-15 18:57:54
|
Ok I have just completed and committed the my short term TODO list C. --=20 Christophe Prud'homme=20 OOA and OOD for Linux CoreLinux -- http://corelinux.sourceforge.net Finite Element Method Codes KFem -- http://kfem.sourceforge.net |
1115 messages has been excluded from this view by a project administrator.
