corelinux-develop

[Corelinux-develop] DEB -2 ?

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

Christophe,

I see you did a repackage of the debian but the file names are the same.
We can do a number of things:

1. Leave them the same and I don't know what will happen when we try to
add to the project
2. Leave them the same and overwrite the anonymous ftp area (mv
debian/xxxx.deb .)
3. Rename them and #1 or #2


Frank

Re: [Corelinux-develop] DEB -2 ?

[Christophe Prud'h. <pru...@MI...>]

>>>>> "Frank" == Frank V Castellucci <fr...@co...> writes:

    Frank> Christophe, I see you did a repackage of the debian but the file names are the same.  We
Hu no I didn't uploaded them yet !

I wasn't able to submit a bug to get a feature number for doxygen
under sourceforge 

to get a new feature I need to go to bug report and submit a bug, right?

C.

[Corelinux-develop] poll

[Christophe Prud'h. <pru...@MI...>]

Hi
just a quick question:
is it desirable to have the inline code(function,enums and defines)
in the reference documentation ?
comments?

-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   If it doesn't work, force it.
  Cambridge MA 02139                     |   If it breaks, it needed
  Tel (Office) : (00 1) (617) 253 0229   |   replacing anyway.
  Fax (Office) : (00 1) (617) 258 8559   |
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] DEB -2 ?

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

Christophe Prud'homme wrote:
> 
> >>>>> "Frank" == Frank V Castellucci <fr...@co...> writes:
> 
>     Frank> Christophe, I see you did a repackage of the debian but the file names are the same.  We
> Hu no I didn't uploaded them yet !
> 
> I wasn't able to submit a bug to get a feature number for doxygen
> under sourceforge
> 
> to get a new feature I need to go to bug report and submit a bug, right?

Yes, there is a bug group called Features

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] poll

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

Christophe Prud'homme wrote:
> 
> Hi
> just a quick question:
> is it desirable to have the inline code(function,enums and defines)
> in the reference documentation ?
> comments?

Yes 

-- 
Frank V. Castellucci

Re: [Corelinux-develop] poll

[Christophe Prud'h. <pru...@MI...>]

    >> Hi just a quick question: is it desirable to have the inline code(function,enums and defines)
    >> in the reference documentation ?  comments?
just to make sure that everything is clear:

the definition of functions enums and defines is included for sure! 
by code I mean all the stuff between the {}s
and doxygen can include those and it looks nice

C.

Re: [Corelinux-develop] poll

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

Christophe Prud'homme wrote:
> 
>     >> Hi just a quick question: is it desirable to have the inline code(function,enums and defines)
>     >> in the reference documentation ?  comments?
> just to make sure that everything is clear:
> 
> the definition of functions enums and defines is included for sure!
> by code I mean all the stuff between the {}s
> and doxygen can include those and it looks nice
> 

Yes, I assumed you meant many of the templated inline methods, or some
of the optimized inline on non-templated class declarations.

-- 
Frank V. Castellucci

[Corelinux-develop] package .deb

[Christophe Prud'h. <pru...@MI...>]

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)
- shared libraries  problem (I have to understand the versioning system :))
- rename to -lcl++ (piece of cake but have to change the packaging)


C.

Re: [Corelinux-develop] package .deb

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

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

[Corelinux-develop] shared libraries versioning using libtool

[Christophe Prud'h. <pru...@MI...>]

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.

Re: [Corelinux-develop] shared libraries versioning using libtool

[Hans - D. <dul...@eg...>]

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

Re: [Corelinux-develop] package .deb

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

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

Re: [Corelinux-develop] package .deb

[Christophe Prud'h. <pru...@MI...>]

    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.

Re: [Corelinux-develop] shared libraries versioning using libtool

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

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