On 20.02.2013 19:11, Raphael Neider wrote: > The problem (well, one of the problems, really :-[) with the PIC > libraries is that they intentionally diverged from SDCCs standard > library (before "my" time already, though I did nothing to revert > that). When the library started to diverge, source files were copied > from devices/lib to the pic specific directories in order not to > pollute the common libraries (I assume). In doing so, the build system > would then have to be set-up in a way to gather source files from > various (i.e., two) places, including some ../ location, which (to me, > and seemingly to the original author) looked bad: not self-contained, > hard to split from the rest of the library (as if that was ever going > to happen), and generally possibly tricky when considering > out-of-source builds as well.
Hmm, the other ports manage to do with just a few port-specific lines in the Makefile.in. E.g. when I made the r2k port, I just had to make a small change in the Makefile.in copied from the z80 port to state that I want the generic strlen() instead of a port-specific one. But maybe there's some pic-specific issue I'm overlooking here. Philipp P.S.: The mcs51 port library is a mess of its own though, seems even worse than the pics, with mcs51-specific stuff in the generic files, #ifdef'ed. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
