Re: Bug#800759: RFS: sdcc/3.5.0+dfsg-1
Hi Wookey
On Sunday 04 October 2015 02:34:23 Wookey wrote:
> +++ Wookey [2015-10-03 14:05 +0100]:
> > +++ Gudjon I. Gudjonsson [2015-10-03 13:48 +0200]:
> > > Changes since the last upload:
> > > * New upstream release (Closes: #789831)
> > > * Improve manpages asxxxx and sdcc
> > > * Add manpages sdar, sdas390, sdasrab, sdasstm8, sdastlcs90,
> > >
> > > sdldstm8, sdnm, sdobjcopy, sstm8
> > >
> > > * Remove manpage savr
> > > * Remove patches, 02_fix_spelling and 03_fix_compilation. Fixed
> > >
> > > in upstream.
>
> You also removed 01_disable nonfree. Is that no longer relevant?
No, upstream improved the disable parameters
--disable-non-free \
--disable-pic14-port \
--disable-pic16-port \
does the work
>
> > > * Bump standards version to 3.9.6
> > > * Remove unneeded lines from clean target in rules file
> > > * Update description i control file (Closes: #766325)
> > > * Move sdar from sdcc-ucsim to sdcc
> > > * Add binary file sdldstm8 to sdcc
> > > * Add provides c-compiler to control file (Closes: #768307)
>
> I'm not quite sure about this one. Yes sdcc is a c-compiler, but it's
> not a 'standard' one and if something is depending on c-compiler
> because it doesn't care whether gcc or clang is used, it may not be
> expecting to get sdcc instead?
>
> On the other hand bcc and tcc and gcc-avr also provide it.
>
> There seem to be 8 packages in the archive tha thave this dep:
> icecc, ikiwiki-hosting-web, intercal, ksplice, laby, libinline-c-perl,
> libtool, pmk
>
> How many of those work with sdcc instead of gcc?
>
> The string c-compiler does not appear in policy, so I must admit that
> I'm not quite sure what exactly it is intended to mean/be used for.
>
> I've added this to the bugreport.
Thanks. I am not sure about this either.
>
> > > * Add huge memory model libraries (Closes: #768307)
> > > * Add deoendency on graphicsmagick-imagemagick-compat
> > > * Exclude example code from compression
>
> Any reason why you didn't apply 766478 (use autotools-dev to update
> config.* files for new arches) too? Doing this is in general good
> practice (and as a porter I like to see such bugs fixed :-)
I was not sure about the patch so I wanted to work on the bug after upload of
3.5.0. But since you recommend the patch I will apply it.
>
>
> Apart from those queries I don't see anything amiss.
> I've not checked a clean build due to desperate shortage of disk space.
>
> Assuming that goes OK, I could upload what you have, but I'd prefer to
> see 766478 fixed too, and a bit more discussion abut whether 768307 is
> actually 'right'. (maybe skip that until a conclusion is reached,
> rather than delay uploading what is done).
>
> Wookey
Great. Thanks
I will apply the patch and wait for result on the c-compiler discussion.
Regards
Gudjon
Reply to: