# Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/dev-embedded/sdcc/sdcc-2.3.0.ebuild,v 0.1 2004/01/17 05:04:13 slammer Exp $ inherit eutils S=${WORKDIR}/${PN} DESCRIPTION="SDCC is a Freeware, retargettable, optimizing ANSI - C compiler. The current version targets the Intel 8051, Maxim/Dallas 80DS390/400 and the Zilog Z80 based MCUs." SRC_URI="mirror://sourceforge/sdcc/${P}.tar.gz" HOMEPAGE="http://sdcc.sourceforge.net/" SLOT="0" LICENSE="GPL-2" KEYWORDS="~x86" DEPEND="virtual/glibc" src_compile() { # Clear CFLAGS... breaks with my Flags! unset CFLAGS CXXFLAGS cd ${S} # Fix doc directory echo "docdir = @datadir@/doc/${P}/sdcc" >> Makefile.common.in echo "docdir = '$'(prefix)/doc/${P}/usim" >> sim/ucsim/doc/Makefile.in ./configure \ --prefix=/usr \ || die "configure failed" emake } src_install() { einstall || die dodoc README COPYING ChangeLog } Reproducible: Always Steps to Reproduce: 1. 2. 3. dev-embedded/sdcc
*** Bug 24709 has been marked as a duplicate of this bug. ***
Which CFLAGS/CXXFLAGS don't work?
dragonheart: please check back at Bug 24709 and don't add the package using it's daily snapshots until upstream has started including a date on the daily snapshots. It makes tracking down problems much more difficult.
dragonheart: you asked a question here, so you are CC'd for when it gets answered.
This ebuild is for a stable version -2.3.0 - released 2001-09-29. http://sourceforge.net/project/showfiles.php?group_id=599 I take you point about nightly snaps. Given they said "SDCC is in active development, and many bugs have been fixed since the 2.3.0 release. It is recommended to download one of the nightly snapshots, which are currently at version 2.3.7" (homepage), I'll email them to see if they can do dates on src code. Other snapshots seem to be at a maximium 1 week old. Is this still supportable if we put the code on gentoo mirrors? Thanks for adding me here too.
Dragonheart: Here is the upstream bug I filed waiting for the versioned tarballs http://sourceforge.net/tracker/index.php?func=detail&aid=832148&group_id=599&atid=200599 Since you seem interested in this stuff, add yourself to the dev-embedded mail alias (Ask in #gentoo-dev how to do that).
Robin - thinking along the same lines. Bernhard - maintainer of SDCC web site, in response to my email (embedded - no pun intended) From: Bernhard Held <bernhard@bernhardheld.de> To: Daniel <dragonheart@gentoo.org> Subject: Re: date stamps on source code images Date: Wed, 4 Feb 2004 22:02:00 +0100 Hi Daniel! > A member of the Gentoo comunity has asked for the SDCC to be includes into > the Gentoo package list. To be able to support this properly it would help > us if the source code snapshots has some form of date in their filename > (yyyymmdd preferably). This will enable a consistant tracing between the > program the user builds and the snapshot we think they are building. Ok, I'll have a look. Please give me one or two weeks to fix it. > Also is there any particular nightly snapshot that would exist on the > sourceforge mirrors for more than a week? No. We're convinced the "latest SDCC is the greatest". There's still a lot of work to do, and I hardly can imagine that anybody will maintain an old version. It's simply a problem of "human resources". We're not happy about bug reports on old versions, we're happy if a bug is fixed in CVS. We don't have time to trace anything. I understand that you're thinking in a different way, but this is all I can do. > If not we can mirror it on > Gentoo's mirrors however we are trying to use other consistant mirrors, > such as Sourceforge, for our packages where possible. > > Does a version 2.3.7 or any post 2.3.0 tarball exist mirrored at a > retrievable location? AFAIK: no. I'd prefer if you could mirror the tarballs on your servers. Bernhard
Daniel: an additional response to bernhard on that we're perfectly happy telling users to upgrade when they encounter problems particullarly with development type packages (eg our Zope packages, 2.6.3 is broken upstream so everybody is being told to upgrade to 2.6.4pre). if bernhard would like users to report bugs here first, i'd be perfectly happy with that, and we can escalate them to upstream properly with all the required information.
Bernhard has come thru for us: http://sdcc.sourceforge.net/snapshots/sdcc-src/sdcc-src-x86-linux2.cf.sourceforge.net-20040209.tar.gz however we need to mirror the snapshot tarballs ourselves.
I have adapted the original ebuild to install the nightly snapshot. It takes the date from the ebuild filename so this should be changed to the latest available src snapshot. Its not ideal but I only really did it so I could get an up-to-date version on my gentoo and thought maybe someone else would find it useful. This one installs version 2.3.8. It also works with my CFLAGS (CFLAGS="-O2 -march=athlon-xp -frename-registers -fomit-frame-pointer") so have commented out that line. # Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/dev-embedded/sdcc/sdcc-20040209.ebuild,v 0.1 2004/02/10 22:32:16 supersi2000 Exp $ inherit eutils S=${WORKDIR}/${PN} DESCRIPTION="SDCC is a Freeware, retargettable, optimizing ANSI - C compiler. The current version targets the Intel 8051, Maxim/Dallas 80DS390/400 and the Zilog Z80 based MCUs." SRC_URI="http://sdcc.sourceforge.net/snapshots/sdcc-src/${PN}-src-x86-linux2.cf.sourceforge.net-${PV}.tar.gz" HOMEPAGE="http://sdcc.sourceforge.net/" SLOT="0" LICENSE="GPL-2" KEYWORDS="~x86" DEPEND="virtual/glibc" src_compile() { # Clear CFLAGS... breaks with my Flags! # unset CFLAGS CXXFLAGS cd ${S} # Fix doc directory echo "docdir = @datadir@/doc/${P}/sdcc" >> Makefile.common.in echo "docdir = '$'(prefix)/doc/${P}/usim" >> sim/ucsim/doc/Makefile.in ./configure \ --prefix=/usr \ || die "configure failed" emake } src_install() { einstall || die dodoc README COPYING ChangeLog }
Thanks Simon, ebuild commited with a few addons for documentation.Any probs please tell us.
