New tools and 4.6.99.3

[Steven Johnson]

Joel Sherrill wrote:

> Steven Johnson wrote:
>
>> Ralf Corsepius wrote:
>>
[snip]

>>>> Neither of which are useful for me.  I already use zlib 1.2.3 and
>>>> my zlib is customized, so i cant have both of these.
>>>>  
>>>>     
>>>
>>> Any particular reason for doing so?
>>>
>>>
>>>   
>>
>> Well, yes. Zlib 1.2.3 is bug fixed.  Also, we have patched it so it
>> returns us status information through a decompress operation so we can
>> show the progress of long unzip's, which the library doesnt do
>> normally.  
>
[snip] 

>>
> Then the zlib in RTEMS needs to be updated.  

This may be so, but the difficulty here will be unless a new version of
rtems is released every time a new version of zlib is released, there
will always be times when the version in rtems isn't the latest. Which
in fact highlights my contention.

> If you want your percentage complete
> support in, then it needs to be submitted to the maintainers of zlib. 
> If it gets merged there,
> then I would see no reason to merge the same code in our code base
> until the next zlib release.

I don't think my patches would be very acceptable to the zlib
maintainers, because they introduce a measurable net decrease in
decompress speed, which for us is acceptable, but in the main people
seem to want a zlib thats as fast as possible. We put up with the
decrease because it means we get feedback during the ~8-10 minutes it
takes to decompress, whereas without it, we get no feedback and it takes
~7-9 minutes to decompress.

>
>
> I don't think RTEMS should be encouraging modifications to the
> standard API of
> a standard package.  We don't want to encourage differences between an
> RTEMS version
> of a package and the standard version.

I agree with that, for the obvious reasons.

>
> With that said, I don't see too much trouble with an option to disable
> zlib and pick up another
> version.  Ignoring your case of adding functionality and assuming that
> the verison in RTEMS
> were the latest, it is possible that you could have a version
> optimized for a particular CPU or
> be deferring to some special ASIC for compression.

I agree also with the options you state for the decompress library.

>
> My biggest negative is that this is an option that would NEVER get
> tested since the standard
> builds would never use it and I don't think any RTEMS maintainer would
> go out of their way
> to exercise it.

To be honest, I don't think zlib should be in rtems at all.  As you say,
its a standard library.  If people want to use facilities of RTEMS that
use zlib, they should get zlib, and build it for their target.  pppd, or
any other part of rtems that uses zlib, need only be told where the
headers are.

An example would be:

./configure --with-zlib=../custom-lib/zlib/include

Unless --with-zlib is specified in the build, those things that rely on
zlib, like pppd shouldnt build, because of failed dependencies.  This (i
believe) is exactly the sort of thing ./configure is designed for.  I
fear if standard libraries (that are not customised to rtems in some
way) are included in rtems, it will become a version maintenance issue. 
Taken to extreme, why not include the source for newlib in the rtems
tree, most every project using rtems probably uses newlib as its
standard library (i don't, but i don't claim to have a usual case).  I
don't think anyone would argue that newlib should be in the tree, i
don't really see the difference with zlib. 

Another approach would be to just put the required headers for zlib to
build pppd or any other code using zlib in the tree.  Build against
those headers.  When the user then links, if they use pppd (or whatever)
and they havent linked in an appropriate zlib, they will get link
errors.  I wouldnt expect these headers would be installed when rtems is
installed, just used to declare the exports of the "standard" zlib
library.  In this way if the "binary" interface to zlib supported by
rtems doesnt change, then any version of zlib supporting that interface
will be fine for the application to ultimately link.  Ie, there would be
no problem linking either 1.2.2 or 1.2.3 as the interface API is the same.

I think both of these solutions may get past the "an option that would
NEVER get tested" issue, which i completely understand the concern for.

I also don't want to overstate the issue, its just one that occurred to
me while moving my application over to 4.6.99.3.  I have effectively
worked around the problem (for me), by just having my script which
builds rtems, deleting all of the zlib files after install.  A brute
force approach, but one that gets me where i need to be.  I am really
just raising it, because I question the merits of including it in the
first place.  If the decision is ultimately to leave it the way it is, I
can live with that, and you wont hear any more about it from me.

Steven