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 attachment 53602 [details] 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 attachment 63615 [details] 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 attachment 66463 [details] 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 attachment 84242 [details] 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 attachment 84245 [details] 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 attachment 85256 [details] 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 attachment 85257 [details] sdcc-variables.patch Patch for the above ebuild.
Created attachment 85436 [details] 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.
