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: Frank V. C. <fr...@co...> - 2000-07-27 21:04:43
|
Christophe Prud'homme wrote:
> Hi,
>
> lots of Linux projects use autoconf out there
> so being able to check corelinux existence using autoconf
> would be nice. Unfortunately autoconf doesn't support well
> C++ in the sense that to check libs it uses a m4 macro
> AC_CHECK_LIB this way
>
> AC_CHECK_LIB(cl++, ACCheckCoreLinux,[
> CXXFLAGS="${CXXFLAGS} -I/usr/include/corelinux"
> LDFLAGS="${LDFLAGS} "
> LIBS="${LIBS} -lcl++"
> ],[
> echo "You need to install corelinux. see http://corelinux.sourceforge.net"
> exit;
> ],)
>
> where cl++ is corelinux lib and ACCheckCoreLinux some symbol to check in cl++
> but the c++ mangler won't create the symbol ACCheckCoreLinux(more likely
> ACCheckCoreLinux__Fv) and AC_CHECK_LIB will create a C program
>
> char ACCheckCoreLinux();
>
> int main() {
> ACCheckCoreLinux()
> ; return 0; }
>
> and the above test will fail :(
> that is bad !
>
> So people have to create their own checking m4 macros for corelinux
> or bypass the checking of corelinux existence.
>
> We can help them by proving this symbol in corelinux
> by defining this dummy function using extern "C"
>
> extern "C" {
> int
> ACCheckCoreLinux()
> {
> return 1;
> }
>
> and put it in libcl++
> and yes it should be documented in the Developper manual
> so that any autoconf user will be very happy. (see the macro above)
>
> well I have already done it in my cvs copy.
>
> comments?
Just put it into it's own module in the src/classlib/corelinux , like where we may
end up putting _init and so on, call it corelinux.cpp and viola if it is not too
late.
>
>
> it seems I like long mails recently :)
> C.
>
> --
> Christophe Prud'homme |
> MIT, 77, Mass Ave, Rm 3-243 | He that breaks a thing to find out
> Cambridge MA 02139 | what it is has left the path of wisdom.
> Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien
> Fax (Office) : (00 1) (617) 258 8559 |
> http://augustine.mit.edu/~prudhomm |
> Following the hacker spirit
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-27 20:56:24
|
Hi,
lots of Linux projects use autoconf out there
so being able to check corelinux existence using autoconf
would be nice. Unfortunately autoconf doesn't support well
C++ in the sense that to check libs it uses a m4 macro
AC_CHECK_LIB this way
AC_CHECK_LIB(cl++, ACCheckCoreLinux,[
CXXFLAGS="${CXXFLAGS} -I/usr/include/corelinux"
LDFLAGS="${LDFLAGS} "
LIBS="${LIBS} -lcl++"
],[
echo "You need to install corelinux. see http://corelinux.sourceforge.net"
exit;
],)
where cl++ is corelinux lib and ACCheckCoreLinux some symbol to check in cl++
but the c++ mangler won't create the symbol ACCheckCoreLinux(more likely
ACCheckCoreLinux__Fv) and AC_CHECK_LIB will create a C program
char ACCheckCoreLinux();
int main() {
ACCheckCoreLinux()
; return 0; }
and the above test will fail :(
that is bad !
So people have to create their own checking m4 macros for corelinux
or bypass the checking of corelinux existence.
We can help them by proving this symbol in corelinux
by defining this dummy function using extern "C"
extern "C" {
int
ACCheckCoreLinux()
{
return 1;
}
and put it in libcl++
and yes it should be documented in the Developper manual
so that any autoconf user will be very happy. (see the macro above)
well I have already done it in my cvs copy.
comments?
it seems I like long mails recently :)
C.
--
Christophe Prud'homme |
MIT, 77, Mass Ave, Rm 3-243 | He that breaks a thing to find out
Cambridge MA 02139 | what it is has left the path of wisdom.
Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien
Fax (Office) : (00 1) (617) 258 8559 |
http://augustine.mit.edu/~prudhomm |
Following the hacker spirit
|
|
From: Frank V. C. <fr...@co...> - 2000-07-27 18:43:33
|
Christophe Prud'homme wrote: > >>>>> "Frank" == Frank V Castellucci <fr...@co...> writes: > > Frank> Christophe Prud'homme wrote: > > Frank> 1. Am I correct you pulled doxygens cvs tree and built with your > Frank> patches? > >> yes but my patches allowed doxygen to generate the doc for pdflatex and the associated > >> makefile did you install doxygen? > Frank> I dl'ed the rpm but I stopped from installing because I remembered your patch note. I > Frank> guess I'll get the CVS and ask for your patch. > Oh it will work perfectly without my patches > my patches are only for pdf generation and in a cosmetic way ! Ok, will install when I get back home. > Frank> 2. In the corelinux.cfg there is a version defined. This, I take it, is > Frank> manually updated for each release? > >> yes but using configure we can update this automatically I will do that ! Check > Frank> Have you had enough sleep yet? > actuallly I arrived at 1oclock so I guess I am all right :) > the thing is that the lab is very noisy during the day and > I need to be in a quiet place to be able to work correctly After having two children, I can work on the NY Subway > Frank> I imagine, I guess it's about time for me to learn RPM nuances as I am on a RH > Frank> distribution anyway. Let me see what I can come up with. > there are several tools to create rpm packages > they will create a .spec file I remember seeing some, I will do a full search at some point tonight. > Frank> Will do, I'll test the develop package later tonight. I'll add the others in the > Frank> meantime. > Ok > > I have already made a few changes (like the auto versioning for doxygen) > > did you try to compile the examples with the system I set up? Not yet, I had to leave the comfort of my own home to, you won't believe this, go to work! Which, by the way, I am convinced is to just support my wine intake. Frank |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-27 17:57:39
|
>>>>> "Frank" == Frank V Castellucci <fr...@co...> writes:
Frank> Christophe Prud'homme wrote:
Frank> 1. Am I correct you pulled doxygens cvs tree and built with your
Frank> patches?
>> yes but my patches allowed doxygen to generate the doc for pdflatex and the associated
>> makefile did you install doxygen?
Frank> I dl'ed the rpm but I stopped from installing because I remembered your patch note. I
Frank> guess I'll get the CVS and ask for your patch.
Oh it will work perfectly without my patches
my patches are only for pdf generation and in a cosmetic way !
Frank> 2. In the corelinux.cfg there is a version defined. This, I take it, is
Frank> manually updated for each release?
>> yes but using configure we can update this automatically I will do that !
Frank> Have you had enough sleep yet?
actuallly I arrived at 1oclock so I guess I am all right :)
the thing is that the lab is very noisy during the day and
I need to be in a quiet place to be able to work correctly
Frank> I imagine, I guess it's about time for me to learn RPM nuances as I am on a RH
Frank> distribution anyway. Let me see what I can come up with.
there are several tools to create rpm packages
they will create a .spec file
Frank> Will do, I'll test the develop package later tonight. I'll add the others in the
Frank> meantime.
Ok
I have already made a few changes (like the auto versioning for doxygen)
did you try to compile the examples with the system I set up?
C.
|
|
From: Frank V. C. <fr...@co...> - 2000-07-27 17:42:39
|
Christophe Prud'homme wrote: > Frank> 1. Am I correct you pulled doxygens cvs tree and built with your > Frank> patches? > yes but my patches allowed doxygen to generate the doc for pdflatex and > the associated makefile > did you install doxygen? I dl'ed the rpm but I stopped from installing because I remembered your patch note. I guess I'll get the CVS and ask for your patch. > Frank> 2. In the corelinux.cfg there is a version defined. This, I take it, is > Frank> manually updated for each release? > yes but using configure we can update this automatically > I will do that ! Have you had enough sleep yet? > Frank> First problems found: > it has to happen > I have little control over the redhat packaging I imagine, I guess it's about time for me to learn RPM nuances as I am on a RH distribution anyway. Let me see what I can come up with. > Frank> Using RPM to install the libcorelinux-0.4.26-1.i386.rpm: > > Frank> 1. The entry is put in the database entry "Converted/libs" branch, > Frank> should go into "System Environment/Libraries" > Ok I 'll what I can do I am at work on a contract today, I will get into RPM manifests and whatever later on tonight or during the weekend. > Frank> 2. When uninstalling RPM complains that it can't delete "/" > That's bad very bad behaviour I'll say :) > Frank> If you want I can start tracking these for you in the BugTracking > yes > Will do, I'll test the develop package later tonight. I'll add the others in the meantime. Frank |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-27 17:17:39
|
Frank> Busy person eh? Some questions:
Well yes
I couldn't stop
Frank> 1. Am I correct you pulled doxygens cvs tree and built with your
Frank> patches?
yes but my patches allowed doxygen to generate the doc for pdflatex and
the associated makefile
did you install doxygen?
Frank> 2. In the corelinux.cfg there is a version defined. This, I take it, is
Frank> manually updated for each release?
yes but using configure we can update this automatically
I will do that !
Frank> First problems found:
it has to happen
I have little control over the redhat packaging
Frank> Using RPM to install the libcorelinux-0.4.26-1.i386.rpm:
Frank> 1. The entry is put in the database entry "Converted/libs" branch,
Frank> should go into "System Environment/Libraries"
Ok I 'll what I can do
Frank> 2. When uninstalling RPM complains that it can't delete "/"
That's bad very bad behaviour
Frank> If you want I can start tracking these for you in the BugTracking
yes
yesterday I recompiled kde2 on my machine
and I am an happy man :)
very fast, beautiful feature full, a bliss but still beta
C.
|
|
From: Frank V. C. <fr...@co...> - 2000-07-27 11:40:39
|
First problems found: Using RPM to install the libcorelinux-0.4.26-1.i386.rpm: 1. The entry is put in the database entry "Converted/libs" branch, should go into "System Environment/Libraries" 2. When uninstalling RPM complains that it can't delete "/" If you want I can start tracking these for you in the BugTracking Christophe Prud'homme wrote: > > Hi all, > > I just upgraded my cvs and there a few important changes: > > - added doxygen support > install CVS version of doxygen > everything is at > > http://www.stack.nl/~dimitri/doxygen/index.html > > the patches I sent for pdf might not be in the CVS yet > so the pdf might look ugly > > don't worry I didn't put the reference manual into CVS > you can't generate it using doxygen by doing: > > cd doc > doxygen corelinux.cfg > > corelinux.css is the style sheet for the html files > corelinux.html is the footer for the html files > > - now use -lcl++ to link against corelinux > all the Makefile.am have been change automagically > (see src/testdrivers/update_makefile.pl) > > - now use the libtool versioning system for shared libraries! > > - update package creation > 4 packages are created > > * libcorelinux the same as always > * libcorelinux-dev added manpages ! > * libcorelinux-doc html + ps + pdf reference manual > * libcorelinux-examples the examples for corelinux > o they are ALL in /usr/share/doc/libcorelinux-examples/examples/ > there is a Makefile which automagically generated during the > package creation (see debian/genmake.pl) > o a README.examples explains how to compile the example but > don't fear it is pretty straightforward > > - the package for 0.4.26 (with -1 package version) have been uploaded > to corelinux.sourceforge.net/packages > Please give them a try and tell, especially undeer redhat, if > everything is ok > On debian side I am an happy corelinux user and package maintainer > I learnt a few interesting things tonight :) > > As you can see I had fun this night! > time to go to bed, good night > C. > > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | He that breaks a thing to find out > Cambridge MA 02139 | what it is has left the path of wisdom. > Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien > Fax (Office) : (00 1) (617) 258 8559 | > 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: Frank V. C. <fr...@co...> - 2000-07-27 11:27:07
|
Busy person eh? Some questions: 1. Am I correct you pulled doxygens cvs tree and built with your patches? 2. In the corelinux.cfg there is a version defined. This, I take it, is manually updated for each release? Maybe more to come Christophe Prud'homme wrote: > > Hi all, > > I just upgraded my cvs and there a few important changes: > > - added doxygen support > install CVS version of doxygen > everything is at > > http://www.stack.nl/~dimitri/doxygen/index.html > > the patches I sent for pdf might not be in the CVS yet > so the pdf might look ugly > > don't worry I didn't put the reference manual into CVS > you can't generate it using doxygen by doing: > > cd doc > doxygen corelinux.cfg > > corelinux.css is the style sheet for the html files > corelinux.html is the footer for the html files > > - now use -lcl++ to link against corelinux > all the Makefile.am have been change automagically > (see src/testdrivers/update_makefile.pl) > > - now use the libtool versioning system for shared libraries! > > - update package creation > 4 packages are created > > * libcorelinux the same as always > * libcorelinux-dev added manpages ! > * libcorelinux-doc html + ps + pdf reference manual > * libcorelinux-examples the examples for corelinux > o they are ALL in /usr/share/doc/libcorelinux-examples/examples/ > there is a Makefile which automagically generated during the > package creation (see debian/genmake.pl) > o a README.examples explains how to compile the example but > don't fear it is pretty straightforward > > - the package for 0.4.26 (with -1 package version) have been uploaded > to corelinux.sourceforge.net/packages > Please give them a try and tell, especially undeer redhat, if > everything is ok > On debian side I am an happy corelinux user and package maintainer > I learnt a few interesting things tonight :) > > As you can see I had fun this night! > time to go to bed, good night > C. > > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | He that breaks a thing to find out > Cambridge MA 02139 | what it is has left the path of wisdom. > Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien > Fax (Office) : (00 1) (617) 258 8559 | > 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-07-27 08:25:31
|
As I said the manual pages are in libcorelinux-dev doxygen generates the name of the manual pages using the namespace and the object or the interface to viewing StorageException manual pages you type man corelinux__StorageException C. |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-27 08:02:48
|
Hi all, I just upgraded my cvs and there a few important changes: - added doxygen support install CVS version of doxygen everything is at http://www.stack.nl/~dimitri/doxygen/index.html the patches I sent for pdf might not be in the CVS yet so the pdf might look ugly don't worry I didn't put the reference manual into CVS you can't generate it using doxygen by doing: cd doc doxygen corelinux.cfg corelinux.css is the style sheet for the html files corelinux.html is the footer for the html files - now use -lcl++ to link against corelinux all the Makefile.am have been change automagically (see src/testdrivers/update_makefile.pl) - now use the libtool versioning system for shared libraries! - update package creation 4 packages are created * libcorelinux the same as always * libcorelinux-dev added manpages ! * libcorelinux-doc html + ps + pdf reference manual * libcorelinux-examples the examples for corelinux o they are ALL in /usr/share/doc/libcorelinux-examples/examples/ there is a Makefile which automagically generated during the package creation (see debian/genmake.pl) o a README.examples explains how to compile the example but don't fear it is pretty straightforward - the package for 0.4.26 (with -1 package version) have been uploaded to corelinux.sourceforge.net/packages Please give them a try and tell, especially undeer redhat, if everything is ok On debian side I am an happy corelinux user and package maintainer I learnt a few interesting things tonight :) As you can see I had fun this night! time to go to bed, good night C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | He that breaks a thing to find out Cambridge MA 02139 | what it is has left the path of wisdom. Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-07-27 00:20:23
|
Christophe Prud'homme wrote: > > req4865.php > > I just had a look > I already implemented such a thing but very basic > expecially the interface type > I am going to play with this :) As my past five (5) years have been spent around descriptive logic, meta-models, ontologies, knowledge representation, I have done alot of this. But, I can't recreate all that is REALLY neccessary because, after all, there is CORBA and RMI to use for that. We need a mini-class declarative object for the arguments in our part of the implementation, the danger with that is it becomes the standard through the frameworks and applications. The really cool thing is this with a Bridge or Adapter pattern for true plug-in framework extensions. > I delegate more and more to corelinux in my own code :) Is this because you are a part of it, or it really has the value I hoped people would find? > > more feedback soon > C. > > _______________________________________________ > 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: Frank V. C. <fr...@co...> - 2000-07-27 00:00:20
|
Christophe Prud'homme wrote: > > Hi, > > with the new reference manual I change the package creation > we have four packages now: > > 1- libcorelinux > shared libs to be able to run corelinux based code on any machines > 2- libcorelinux-dev > static lib + header files > 3- libcorelinux-doc > reference manual in html latex and nroff > * html and latex go in /usr/doc/corelinux/ > * manual pages go in /usr/share/man/man3 > Note that you won't have the ref manual in the cvs only the doxygen > file and then when I create the packages doxygen is executed and I > create the manual > 4- libcorelinux-examples > all the examples from the sources > there is a little problem with that since the makefiles were made to work > inside the corelinux src environement > so they will not work > any ideas? I didn't think about it yet so I might find an easy answer if > I work on it I assume I will continue creating the tarball source distribution? I think for #4 you need to approach it as though the only thing you have to start with is a class library (libcorelinux) and you are creating a series of mini-apps for distribution, including, and I know you'll groan over this, automake and autoconf. Or, we create a SRC-RPM for the examples. This may require a RPM manifest and whatever is equivalent in DEB to name dependencies. > > This is not finished but it is working > 1- I have still to change the lib names > 2- I have to fix the shared lib problem > 3- finished fixing doxygen/corelinux warnings > > comments? > > -- > 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 > > _______________________________________________ > 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-07-26 23:16:17
|
Hi, with the new reference manual I change the package creation we have four packages now: 1- libcorelinux shared libs to be able to run corelinux based code on any machines 2- libcorelinux-dev static lib + header files 3- libcorelinux-doc reference manual in html latex and nroff * html and latex go in /usr/doc/corelinux/ * manual pages go in /usr/share/man/man3 Note that you won't have the ref manual in the cvs only the doxygen file and then when I create the packages doxygen is executed and I create the manual 4- libcorelinux-examples all the examples from the sources there is a little problem with that since the makefiles were made to work inside the corelinux src environement so they will not work any ideas? I didn't think about it yet so I might find an easy answer if I work on it This is not finished but it is working 1- I have still to change the lib names 2- I have to fix the shared lib problem 3- finished fixing doxygen/corelinux warnings comments? -- 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: Christophe Prud'h. <pru...@MI...> - 2000-07-26 22:30:45
|
req4865.php I just had a look I already implemented such a thing but very basic expecially the interface type I am going to play with this :) I delegate more and more to corelinux in my own code :) more feedback soon C. |
|
From: Hans - D. <dul...@eg...> - 2000-07-26 17:23:29
|
On Wed, 26 Jul 2000, Christophe Prud'homme wrote: > Date: Wed, 26 Jul 2000 11:06:40 -0400 (EDT) > From: Christophe Prud'homme <pru...@MI...> > Reply-To: cor...@li... > To: cor...@li... > Subject: [Corelinux-develop] shared libraries versioning using libtool > > Hi all, > > I took this from libtool manual > > > > The plan: > > I- What are library interfaces? > II- Libtool's versioning system > III- Updating library version information > > > What I propose is, > > let's begin with: > > - CURRENT=0 > - REVISION=0 > - AGE=0 > it is quite sound because corelinux is in a stable state now > > then if > > - code source is changed: REVISION+=1 > - some library interfaces are changed > CURRENT += 1 (if existing interfaces are changed) > REVISION = 0 > - if any interfaces(ner class) have been added: AGE+=1 (CURRENT has not been increased) > - if interfaces(remove a member function or a class) have been removed AGE=0 (CURRENT has been increased) > > some scenarios: > --------------- > ** if an existing interface is changed then it means that the library is not binary compatible anymore so > CURRENT+=1 > ** if code source is changed then the lib is still binary compatible so just do a REVISION+=1 > ** if a new interface(a new class for example) is added then the lib > is still binary compatible but a new interface is available (old > code should work) just do an AGE+=1 > > comments ? Sound good to me, so we have a systematic of of numbering the release. > have a good reading! > > ================================================================================ > > I- What are library interfaces? > =============================== > > Interfaces for libraries may be any of the following (and more): > > * global variables: both names and types > > * global functions: argument types and number, return types, and > function names > > * standard input, standard output, standard error, and file formats > > * sockets, pipes, and other inter-process communication protocol > formats > > Note that static functions do not count as interfaces, because they > are not directly available to the user of the library. > > II- Libtool's versioning system > ================================ > > Libtool has its own formal versioning system. It is not as flexible > as some, but it is definitely the simplest of the more powerful > versioning systems. > > Think of a library as exporting several sets of interfaces, > arbitrarily represented by integers. When a program is linked against > a library, it may use any subset of those interfaces. > > Libtool's description of the interfaces that a program uses is > simple: it encodes the least and the greatest interface numbers in the > resulting binary (FIRST-INTERFACE, LAST-INTERFACE). > > The dynamic linker is guaranteed that if a library supports _every_ > interface number between FIRST-INTERFACE and LAST-INTERFACE, then the > program can be relinked against that library. > > Note that this can cause problems because libtool's compatibility > requirements are actually stricter than is necessary. > > Say `libhello' supports interfaces 5, 16, 17, 18, and 19, and that > libtool is used to link `test' against `libhello'. > > Libtool encodes the numbers 5 and 19 in `test', and the dynamic > linker will only link `test' against libraries that support _every_ > interface between 5 and 19. So, the dynamic linker refuses to link > `test' against `libhello'! > > In order to eliminate this problem, libtool only allows libraries to > declare consecutive interface numbers. So, `libhello' can declare at > most that it supports interfaces 16 through 19. Then, the dynamic > linker will link `test' against `libhello'. > > So, libtool library versions are described by three integers: > > CURRENT > The most recent interface number that this library implements. > > REVISION > The implementation number of the CURRENT interface. > > AGE > The difference between the newest and oldest interfaces that this > library implements. In other words, the library implements all the > interface numbers in the range from number `CURRENT - AGE' to > `CURRENT'. > > If two libraries have identical CURRENT and AGE numbers, then the > dynamic linker chooses the library with the greater REVISION number. > > > III- Updating library version information > ========================================= > > If you want to use libtool's versioning system, then you must specify > the version information to libtool using the `-version-info' flag > during link mode (*note Link mode::). > > This flag accepts an argument of the form > `CURRENT[:REVISION[:AGE]]'. So, passing `-version-info 3:12:1' sets > CURRENT to 3, REVISION to 12, and AGE to 1. > > If either REVISION or AGE are omitted, they default to 0. Also note > that AGE must be less than or equal to the CURRENT interface number. > > Here are a set of rules to help you update your library version > information: > > 1. Start with version information of `0:0:0' for each libtool library. > > 2. Update the version information only immediately before a public > release of your software. More frequent updates are unnecessary, > and only guarantee that the current interface number gets larger > faster. > > 3. If the library source code has changed at all since the last > update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). > > 4. If any interfaces have been added, removed, or changed since the > last update, increment CURRENT, and set REVISION to 0. > > 5. If any interfaces have been added since the last public release, > then increment AGE. > > 6. If any interfaces have been removed since the last public release, > then set AGE to 0. > > [IMPORTANT NOTICE] > > *_Never_* try to set the interface numbers so that they correspond > to the release number of your package. This is an abuse that only > fosters misunderstanding of the purpose of library versions. Instead, > use the `-release' flag (*note Release numbers::), but be warned that > every release of your package will not be binary compatible with any > other release. > > > regards > C. > > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop > -- Hans Dulimarta, Ph.D. dulimart@[egr.msu.edu, computer.org] Visiting Research Associate http://www.egr.msu.edu/%7edulimart Ph: (517)432-7589 Fax2Email: (760)281-7691 Elec. & Comp. Engg., Michigan State University, East Lansing, MI 48824 |
|
From: Frank V. C. <fr...@co...> - 2000-07-26 15:36:49
|
Yes, if you look in ~/corelinux/configure.in you will see I have this commented out from previous analysis. Christophe Prud'homme wrote: > > Hi all, > > I took this from libtool manual > > The plan: > > I- What are library interfaces? > II- Libtool's versioning system > III- Updating library version information > > What I propose is, > > let's begin with: > > - CURRENT=0 > - REVISION=0 > - AGE=0 > it is quite sound because corelinux is in a stable state now > > then if > > - code source is changed: REVISION+=1 > - some library interfaces are changed > CURRENT += 1 (if existing interfaces are changed) > REVISION = 0 > - if any interfaces(ner class) have been added: AGE+=1 (CURRENT has not been increased) > - if interfaces(remove a member function or a class) have been removed AGE=0 (CURRENT has been increased) > > some scenarios: > --------------- > ** if an existing interface is changed then it means that the library is not binary compatible anymore so > CURRENT+=1 > ** if code source is changed then the lib is still binary compatible so just do a REVISION+=1 > ** if a new interface(a new class for example) is added then the lib > is still binary compatible but a new interface is available (old > code should work) just do an AGE+=1 > > comments ? > have a good reading! > > ================================================================================ > > I- What are library interfaces? > =============================== > > Interfaces for libraries may be any of the following (and more): > > * global variables: both names and types > > * global functions: argument types and number, return types, and > function names > > * standard input, standard output, standard error, and file formats > > * sockets, pipes, and other inter-process communication protocol > formats > > Note that static functions do not count as interfaces, because they > are not directly available to the user of the library. > > II- Libtool's versioning system > ================================ > > Libtool has its own formal versioning system. It is not as flexible > as some, but it is definitely the simplest of the more powerful > versioning systems. > > Think of a library as exporting several sets of interfaces, > arbitrarily represented by integers. When a program is linked against > a library, it may use any subset of those interfaces. > > Libtool's description of the interfaces that a program uses is > simple: it encodes the least and the greatest interface numbers in the > resulting binary (FIRST-INTERFACE, LAST-INTERFACE). > > The dynamic linker is guaranteed that if a library supports _every_ > interface number between FIRST-INTERFACE and LAST-INTERFACE, then the > program can be relinked against that library. > > Note that this can cause problems because libtool's compatibility > requirements are actually stricter than is necessary. > > Say `libhello' supports interfaces 5, 16, 17, 18, and 19, and that > libtool is used to link `test' against `libhello'. > > Libtool encodes the numbers 5 and 19 in `test', and the dynamic > linker will only link `test' against libraries that support _every_ > interface between 5 and 19. So, the dynamic linker refuses to link > `test' against `libhello'! > > In order to eliminate this problem, libtool only allows libraries to > declare consecutive interface numbers. So, `libhello' can declare at > most that it supports interfaces 16 through 19. Then, the dynamic > linker will link `test' against `libhello'. > > So, libtool library versions are described by three integers: > > CURRENT > The most recent interface number that this library implements. > > REVISION > The implementation number of the CURRENT interface. > > AGE > The difference between the newest and oldest interfaces that this > library implements. In other words, the library implements all the > interface numbers in the range from number `CURRENT - AGE' to > `CURRENT'. > > If two libraries have identical CURRENT and AGE numbers, then the > dynamic linker chooses the library with the greater REVISION number. > > III- Updating library version information > ========================================= > > If you want to use libtool's versioning system, then you must specify > the version information to libtool using the `-version-info' flag > during link mode (*note Link mode::). > > This flag accepts an argument of the form > `CURRENT[:REVISION[:AGE]]'. So, passing `-version-info 3:12:1' sets > CURRENT to 3, REVISION to 12, and AGE to 1. > > If either REVISION or AGE are omitted, they default to 0. Also note > that AGE must be less than or equal to the CURRENT interface number. > > Here are a set of rules to help you update your library version > information: > > 1. Start with version information of `0:0:0' for each libtool library. > > 2. Update the version information only immediately before a public > release of your software. More frequent updates are unnecessary, > and only guarantee that the current interface number gets larger > faster. > > 3. If the library source code has changed at all since the last > update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). > > 4. If any interfaces have been added, removed, or changed since the > last update, increment CURRENT, and set REVISION to 0. > > 5. If any interfaces have been added since the last public release, > then increment AGE. > > 6. If any interfaces have been removed since the last public release, > then set AGE to 0. > > [IMPORTANT NOTICE] > > *_Never_* try to set the interface numbers so that they correspond > to the release number of your package. This is an abuse that only > fosters misunderstanding of the purpose of library versions. Instead, > use the `-release' flag (*note Release numbers::), but be warned that > every release of your package will not be binary compatible with any > other release. > > regards > C. > > _______________________________________________ > 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-07-26 15:06:43
|
Hi all,
I took this from libtool manual
The plan:
I- What are library interfaces?
II- Libtool's versioning system
III- Updating library version information
What I propose is,
let's begin with:
- CURRENT=0
- REVISION=0
- AGE=0
it is quite sound because corelinux is in a stable state now
then if
- code source is changed: REVISION+=1
- some library interfaces are changed
CURRENT += 1 (if existing interfaces are changed)
REVISION = 0
- if any interfaces(ner class) have been added: AGE+=1 (CURRENT has not been increased)
- if interfaces(remove a member function or a class) have been removed AGE=0 (CURRENT has been increased)
some scenarios:
---------------
** if an existing interface is changed then it means that the library is not binary compatible anymore so
CURRENT+=1
** if code source is changed then the lib is still binary compatible so just do a REVISION+=1
** if a new interface(a new class for example) is added then the lib
is still binary compatible but a new interface is available (old
code should work) just do an AGE+=1
comments ?
have a good reading!
================================================================================
I- What are library interfaces?
===============================
Interfaces for libraries may be any of the following (and more):
* global variables: both names and types
* global functions: argument types and number, return types, and
function names
* standard input, standard output, standard error, and file formats
* sockets, pipes, and other inter-process communication protocol
formats
Note that static functions do not count as interfaces, because they
are not directly available to the user of the library.
II- Libtool's versioning system
================================
Libtool has its own formal versioning system. It is not as flexible
as some, but it is definitely the simplest of the more powerful
versioning systems.
Think of a library as exporting several sets of interfaces,
arbitrarily represented by integers. When a program is linked against
a library, it may use any subset of those interfaces.
Libtool's description of the interfaces that a program uses is
simple: it encodes the least and the greatest interface numbers in the
resulting binary (FIRST-INTERFACE, LAST-INTERFACE).
The dynamic linker is guaranteed that if a library supports _every_
interface number between FIRST-INTERFACE and LAST-INTERFACE, then the
program can be relinked against that library.
Note that this can cause problems because libtool's compatibility
requirements are actually stricter than is necessary.
Say `libhello' supports interfaces 5, 16, 17, 18, and 19, and that
libtool is used to link `test' against `libhello'.
Libtool encodes the numbers 5 and 19 in `test', and the dynamic
linker will only link `test' against libraries that support _every_
interface between 5 and 19. So, the dynamic linker refuses to link
`test' against `libhello'!
In order to eliminate this problem, libtool only allows libraries to
declare consecutive interface numbers. So, `libhello' can declare at
most that it supports interfaces 16 through 19. Then, the dynamic
linker will link `test' against `libhello'.
So, libtool library versions are described by three integers:
CURRENT
The most recent interface number that this library implements.
REVISION
The implementation number of the CURRENT interface.
AGE
The difference between the newest and oldest interfaces that this
library implements. In other words, the library implements all the
interface numbers in the range from number `CURRENT - AGE' to
`CURRENT'.
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
III- Updating library version information
=========================================
If you want to use libtool's versioning system, then you must specify
the version information to libtool using the `-version-info' flag
during link mode (*note Link mode::).
This flag accepts an argument of the form
`CURRENT[:REVISION[:AGE]]'. So, passing `-version-info 3:12:1' sets
CURRENT to 3, REVISION to 12, and AGE to 1.
If either REVISION or AGE are omitted, they default to 0. Also note
that AGE must be less than or equal to the CURRENT interface number.
Here are a set of rules to help you update your library version
information:
1. Start with version information of `0:0:0' for each libtool library.
2. Update the version information only immediately before a public
release of your software. More frequent updates are unnecessary,
and only guarantee that the current interface number gets larger
faster.
3. If the library source code has changed at all since the last
update, then increment REVISION (`C:R:A' becomes `C:r+1:A').
4. If any interfaces have been added, removed, or changed since the
last update, increment CURRENT, and set REVISION to 0.
5. If any interfaces have been added since the last public release,
then increment AGE.
6. If any interfaces have been removed since the last public release,
then set AGE to 0.
[IMPORTANT NOTICE]
*_Never_* try to set the interface numbers so that they correspond
to the release number of your package. This is an abuse that only
fosters misunderstanding of the purpose of library versions. Instead,
use the `-release' flag (*note Release numbers::), but be warned that
every release of your package will not be binary compatible with any
other release.
regards
C.
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-26 14:20:17
|
>>>>> "Frank" == Frank V Castellucci <fr...@co...> writes:
Frank> Not powerful enough for what documentation CoreLinux++ has? Or for your mathematical
Frank> equation requirements in your documentation?
no for corelinux lyx is really good
and for lots of things
but I am a mathematician
and I type in and use xemacs very quickly so I don't want lo lose productivity
and it is good to have the same kind of environment all the time
(something like reusable components :) )
C.
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-26 14:17:33
|
Frank> which will result in libcl++.so, libcl++.so.0 and libcl++.so.0.4.26 in the immediate
Frank> versioning oui?
shared lib versioning does not work this
I will explain it in a forthcoming mail
but yes we will have -lcl++.so -lcl++.a -lcl++.so.x.y.z (will be different
from 0x.4.26)
C.
|
|
From: Frank V. C. <fr...@co...> - 2000-07-26 14:13:55
|
I would ask for feedback on http://corelinux.sourceforge.net/doc/requirements/req4865.php. Pay close attention to the design classes and diagram as the requirement text is out of synch. It is a interesting pattern in that it considers: 1. All libraries are not just of a *.so type, therefore allowing loaders to handle any kind of load request 2. Objects in a library need some kind of meta-definition for reasoning by the loader and the application 3. The immediate use and implementation of the team will be limited to function libraries (*.so) with a common ABI (C). 4. This leaves the door open for the framework work of adding class types dynamically plugged-in (Christophe may be keen on this) or CORBA resolution handlers, or any other thing. -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-07-26 12:44:22
|
Ok, it comes down to 6, 9, and 12 for mikes entries. Any more thoughts on this? Anyone? -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-07-26 12:02:51
|
Christophe Prud'homme wrote: > > I saw in the archives some mails mentioning TeXmacs, what is that? > > I gave a look at lyx and klyx but they are not powerful enough > My preference goes to Xemacs(using auctex reftex and x-symbol) for now > auctex and reftex come with xemacs > whereas you have to download xsymbol > > http://www.fmi.uni-passau.de/~wedler/x-symbol/ > > good night > C. > Not powerful enough for what documentation CoreLinux++ has? Or for your mathematical equation requirements in your documentation? -- 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...> - 2000-07-26 11:54:54
|
Christophe Prud'homme wrote: > > I just uploaded the -2 packages for debian in /home/groups/corelinux/packages > > I am now working on: > - rename to -lcl++ (piece of cake but have to change the packaging) which will result in libcl++.so, libcl++.so.0 and libcl++.so.0.4.26 in the immediate versioning oui? > > C. > > _______________________________________________ > 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: Frank V. C. <fr...@co...> - 2000-07-26 11:50:48
|
Christophe Prud'homme wrote: > > I just uploaded the -2 packages for debian in /home/groups/corelinux/packages > > I am now working on: > - doxygen stuff (almost done: need to fix some warnings) cool > - shared libraries problem (I have to understand the versioning system :)) I am afraid that you may run into some problems here as the major.minor.maintenance values were not passed to the link step correctly in the past. Which is why we have what we have. Until which point OUR versioning reached 1.0.0, we were going to lay off the library managers versioning. Obviously if this is something that is correctable, by all means have at it. > - rename to -lcl++ (piece of cake but have to change the packaging) you may need to s/libcorelinux/lcl/ in a number of docs as well. -- Frank V. Castellucci |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-07-26 04:07:54
|
I saw in the archives some mails mentioning TeXmacs, what is that? I gave a look at lyx and klyx but they are not powerful enough My preference goes to Xemacs(using auctex reftex and x-symbol) for now auctex and reftex come with xemacs whereas you have to download xsymbol http://www.fmi.uni-passau.de/~wedler/x-symbol/ good night C. |