Bugzilla Bug 85467

http://ubicomp.lancs.ac.uk/~martyn/sdcc_linux/ lists steps required to build
include files for sdcc for the microchip PIC family of chips. Attached ebuild
performs these steps in the presense of the pic16 use flag.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=53602) [edit]
new ebuild with pic16 support

dev-embedded/sdcc-cvs/sdcc-cvs-2.4.0-r2.ebuild

I think the ebuild you've made installs the pic14bit headers (which strangely
seems to refer to PIC16xxxx chips). pic16 in sdcc terminology confusingly
refers to PIC18xxxx chips. It could do to install the pic libraries as well 

http://ubicomp.lancs.ac.uk/~martyn/sdcc_linux/
"Installing PIC16 Libraries

SDCC includes a number of libraries which have been written for the PIC16
family of microcontroller, this family of PICs are generally labeled PIC18fxxx
or PIC18fxxxx. These libraries include functions for initialising the PIC,
utilising I2C, math operations and even some functions for printing to the
stdout (where ever that may be). These libraries are not compiled and installed
as part of the main install and thus must be done separately as not all users
of SDCC will be creating PIC16 projects. To build the libraries:
cd /<path to sdcc source>/device/lib/pic16/
./configure
make all

The build for I/O libraries is also separated out as these are required to be
built for each supported device individually and this can be time consuming. It
is possible to limit the devices that the make process builds for by editing
the "pics.build" file. The following command makes the I/O Libraries:
make lib-io

The library build then needs to be completed and the libraries then need to be
copied to there correct locations:
cd ..
make model-pic16
make install

Lastly the header files must be copied to there correct locations:
cd ../include/
make install"

Yep, you're exactly right. The ebuild builds compile headers for the pic16xxx
family of chips which are actually 14bit processors.

Created an attachment (id=63615) [edit]
New SDCC Ebuild with PIC16Fxx amd PIC18Fxx and libs

Use pic14 to compile support for 16Fxx series and pic16 to compile for 18Fxx
series. Relies on GPUtils 0.13.2

Created an attachment (id=66463) [edit]
sdcc-2.5.0_p20050820.ebuild

I did a bit of a cleanup. I'm getting a compile error with this. Aman and Shaun
if you have some time can you debug this a touch further.

Also if there is no negative consequences is it possible to just install the
pic14 and pic16 versions without discriminating on use flag?

Sorry for the delay too - was moving house about when the bug was lodged and
didn't get around to catching up.

My error:

make[4]: Leaving directory
`/var/tmp/portage/sdcc-2.5.0_p20050820/work/sdcc/device/lib/pic16/startup'
make[3]: Leaving directory
`/var/tmp/portage/sdcc-2.5.0_p20050820/work/sdcc/device/lib/pic16'
cd build/pic16; ls *.lib > pic16.lib
ls: *.lib: No such file or directory
make[2]: *** [objects-pic16] Error 1
make[2]: Leaving directory
`/var/tmp/portage/sdcc-2.5.0_p20050820/work/sdcc/device/lib'
make[1]: *** [model-pic16] Error 2
make[1]: Leaving directory
`/var/tmp/portage/sdcc-2.5.0_p20050820/work/sdcc/device/lib'
make: *** [sdcc-device] Error 2

!!! ERROR: dev-embedded/sdcc-2.5.0_p20050820 failed.
!!! Function src_compile, Line 33, Exitcode 2

Got the same problem here too. Though the build goes fine outside portage, in
portage it fails at the first make.
I ran plain ./configure && make.
As for the subsequent make commands;
With the latest CVS (see date) the command "make lib-io" no longer works. It
looks like the IO-stuff is already build, as much of the other stuff. I think we
can do away with all the extra make commands without getting punnished ;)
Only the "make install" commands are usefull (just to be sure).
First stop make command #1 needs repairing :}

Note:
I renamed the ebuild to reflect the latest snapshot (See date).

mvg,

Remy

Created an attachment (id=84242) [edit]
sdcc-2.5.0_p20060408.ebuild

No more access violations ;)
Ik also removed pic14/16 since they are build by default. If someone knows how
to use $(myconf)?
Note:
If you find it not working because the source-file is unavailable, go to the
site of sdcc and see what's the newest snapshot, and change the name (the date
part) of the ebuild. Run `ebuild [ebuild] digest` and you're done

Have fun!

Created an attachment (id=84245) [edit]
sdcc-2.5.0_p20060408.ebuild

Sorry,

Made mistake there :}
This is the one.

Appearently There's no way to build pic support within an ebuild the normal
way. Would it be possible to build gputils within the sandbox, and use it for
sdcc?
For now, I build my sdcc outside portage...

Created an attachment (id=85256) [edit]
sdcc-2.5.0_p20060422.ebuild

Could you guys please try this ebuild and tell me what you think of it ? I used
the 20060422 snapshot but the sdcc cvs hasn't changed in like 3 weeks. Don't
forget to download the patch below.

Created an attachment (id=85257) [edit]
sdcc-variables.patch

Patch for the above ebuild.

Created an attachment (id=85436) [edit]
sdcc-2.5.0_p20060423.ebuild

Here's a new ebuild, and the story behind it (i.e. changelog) :

Daniel noticed that some residues of documentation were automatically installed
in the wrong place, even without the 'doc' USE flag. This got me started on the
documentation installation with 'doc' this time, and I was very mildly amused
by the lyx dependency. A total of a 110 MB download to install 18 packages,
among which 3 were broken for me (I filed the appropriate bugs), isn't what I
call reasonable. I know that the sdcc's configure script looks for lyx and
complains if it doesn't find it, but I found documentation snapshots matching
every single source snapshot on the sdcc site. Those are automatically made,
and contain the whole documentation in pdf and html form. Today they're just
above 1 MB.

The snapshot is from the 23rd, as, based on the changelog, this seemed a better
choice for a longer term version on our side.

This ebuild also uses the Boehm-Demers-Weiser garbage collector for lower
runtime memory footprint, as sdcc seems to support it fairly well (it works at
least for me).

Finally, I'm not using a patch anymore, but using sed instead. It's less
orthodox, but long-term maintainability of the ebuild is less at risk.

If nobody objects to this one, I'll commit it.

Fixed. sdcc-2.5.0_p20060423 is now in cvs.