Separate packages (was Re: Web Server Patch)

[Joel Sherrill]

Chris Johns wrote:
> 
> Ralf Corsepius wrote:
> > Am Fre, 2003-04-11 um 00.26 schrieb Joel Sherrill:
> >
> >>Till Straumann wrote:
> >>>Please consider making each of these applications a separate
> >>>library, at least.
> >
> > Why? Where are the benefits? I don't see any.
> >
> 
> A couple of questions come to mind. Please excuse answering with questions.
> 
> Should we add more packages ?

See my other post but if it exists as a separate packaeage, let's leave
it
that way.

> For example I have Net SNMP (see the contrib dir) and Python (not full ported)
> running on RTEMS. These are large packages that are constantly being worked on.

And those should end up in the RTEMS contrib with instructions. 
Periodically,
we can update the contrib directory to reflect which one is believed to
be the
best to use with RTEMS.

> If not then what should go in (why?, and who decides?) ?
> 
> Some reasons to keep packages separate are:
> 
> 1) Scalability.
>   a) Putting everything into a single lib slows linking down.
>   b) The more packages you merge together the more revs you need to make.
>   c) Testing time takes longer for Joel who releases the RTEMS package.
>   d) Increased complexity to build it all. RTEMS would need to become
>      a superset of all package build options and configuration. We currently
>      have a range of configure options, header file defines, and runtime
>      options.
> 
> 2) Package Support.
>   a) We should try and keep RTEMS support for a package in the package.
>   b) A stable build environment in a package will easy package upgrades.
>   c) Separate release cycles for each package.

Exactly.  

> On the negative side building an application requires a large stream of lib options.
> 
> Getting package configure scripts to work can be a bigger job than the porting of a
> package. Net-SNMP and Python and good examples of this point.

For MDP and NTP, it was most of the job.  MDP had never been cross built
as far
as I could tell.  NTP was simply complicated with lots of options.  

> --
>   Chris Johns, cjohns at cybertec.com.au