Greetings,
I just implemented release tarball generation (with ChangeLog generation) in the enclosed patch for flashrom's Makefile, diffed against SVN.
This required editing the version parsing rule to make it useful for versioning the tarball filename too. Please check if this still produces the desired effect for the -D CFLAG fragment.
Best Regards,
Hi,
On Wed, Jan 23, 2008 at 09:55:30PM +0200, Martin-Éric Racine wrote:
I just implemented release tarball generation (with ChangeLog generation) in the enclosed patch for flashrom's Makefile, diffed against SVN.
Please send all patches with a Signed-off-by, otherwise we cannot commit. See http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
This required editing the version parsing rule to make it useful for versioning the tarball filename too. Please check if this still produces the desired effect for the -D CFLAG fragment.
Not quite, after running 'make' I get:
cc1: warnings being treated as errors flashrom.c: In function ‘print_version’: flashrom.c:221: warning: format ‘%s’ expects type ‘char *’, but argument 2 has ype ‘int’ make: *** [flashrom.o] Error 1
The fix is easy though, you have to use
CFLAGS += -D'FLASHROM_VERSION="$(SVNDEF)"'
(note the additional quotes)
diff -pruN flashrom/Makefile flashrom.new/Makefile --- flashrom/Makefile 2008-01-23 15:03:54.000000000 +0200 +++ flashrom.new/Makefile 2008-01-23 17:10:05.000000000 +0200 @@ -8,6 +8,7 @@ PROGRAM = flashrom
CC = gcc STRIP = strip +GZIP_ENV = --best INSTALL = /usr/bin/install PREFIX = /usr/local #CFLAGS = -O2 -g -Wall -Werror @@ -30,23 +31,34 @@ all: pciutils dep $(PROGRAM)
# Set the flashrom version string from the highest revision number # of the checked out flashrom files. -SVNDEF := -D'FLASHROM_VERSION="$(shell svnversion -cn . \
| sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'-CFLAGS += $(SVNDEF) +SVNDEF := $(shell svnversion -cn . | sed -e "s/.*://" -e "s/([0-9]*).*/\1/") +CFLAGS += -D'FLASHROM_VERSION=$(SVNDEF)' +DISTDIR= "$(PROGRAM)-r$(SVNDEF)"
$(PROGRAM): $(OBJS) $(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS) $(STRIP) $(STRIP_ARGS) $(PROGRAM)
+ChangeLog:
- svn2cl
I'd make this 'svn log > ChangeLog' or 'svn log -v > ChangeLog' in order to not add the additional dependency on svn2cl. The output is similarly useful, IMO.
Also, the ChangeLog is not included in the tarball at the moment, you have to put it in the flashrom-rXXXX directory before tar'ing it.
Another problem is that the generated tarball cannot correctly build a working version of flashrom. The version number string is not passed correctly, you get
gcc -Os -Wall -Werror -DDISABLE_DOC -D'FLASHROM_VERSION=""' -c -o sst28sf040.o sst28sf040.c
Which leads to a broken --version output. Fixing this is a bit tricky.
Personally, I'm not convinced we want to do tarball releases at all, not sure it's worth the hassle. Definately not "real" releases as in flashrom 0.4.5 or so, but maybe one tarball per svn revision would be nice to put up on the website similar to the svn snapshots which are generated for coreboot? Stefan?
Uwe.
On Fri, Jan 25, 2008 at 03:43:02PM +0100, Uwe Hermann wrote:
Personally, I'm not convinced we want to do tarball releases at all, not sure it's worth the hassle. Definately not "real" releases as in flashrom 0.4.5 or so,
These are very good for distributions. Not all distributions can deal with svn HEAD and few do it well IMO.
but maybe one tarball per svn revision would be nice to put up on the website similar to the svn snapshots which are generated for coreboot? Stefan?
Would definately be a good thing!
For the longer term I'd like a config file for flashrom that is all that ever really changes unless a new bus comes along.
//Peter
Peter Stuge wrote:
On Fri, Jan 25, 2008 at 03:43:02PM +0100, Uwe Hermann wrote:
Personally, I'm not convinced we want to do tarball releases at all, not sure it's worth the hassle. Definately not "real" releases as in flashrom 0.4.5 or so,
These are very good for distributions. Not all distributions can deal with svn HEAD and few do it well IMO.
What would be the problem with a version "r3065"? I doubt any distributions would have a problem with that.
but maybe one tarball per svn revision would be nice to put up on the website similar to the svn snapshots which are generated for coreboot? Stefan?
Would definately be a good thing!
These can be generated using viewvc. I don't want to create another binary graveyard for millions of 0s and 1s ;-)
I am even thinking of getting rid of the tarballs, replacing them by viewvc links. The reason I did not is that viewvc does not honor the +x bit of files in the repo, so the tree migh
For the longer term I'd like a config file for flashrom that is all that ever really changes unless a new bus comes along.
ie. describing all the flash chips? I agree.
On Fri, Jan 25, 2008 at 07:21:16PM +0100, Stefan Reinauer wrote:
These are very good for distributions. Not all distributions can deal with svn HEAD and few do it well IMO.
What would be the problem with a version "r3065"? I doubt any distributions would have a problem with that.
Yeah, fixed svn rev versions can work like any other versions. I would drop r though, at least Gentoo has a problem with non-numeric versions. (Yes, that sucks.)
but maybe one tarball per svn revision
Would definately be a good thing!
These can be generated using viewvc. I don't want to create another binary graveyard for millions of 0s and 1s ;-)
I am even thinking of getting rid of the tarballs, replacing them by viewvc links. The reason I did not is that viewvc does not honor the +x bit of files in the repo, so the tree migh
Hm - causing a problem for directories, or where?
For the longer term I'd like a config file for flashrom that is all that ever really changes unless a new bus comes along.
ie. describing all the flash chips? I agree.
Not just flash, but also how to reach them. I expect other superios to require different tricks than IT8716, so once we have a few more SPI boards we'll also want to teach flashrom which mainboard uses which superio. (By re-using information from coreboot.) Ideally flashrom would then work out whatever it needs to go through the needed hardware on it's own.
This code might even come back into coreboot - for panic room flashing.
//Peter
* Peter Stuge peter@stuge.se [080125 20:24]:
I am even thinking of getting rid of the tarballs, replacing them by viewvc links. The reason I did not is that viewvc does not honor the +x bit of files in the repo, so the tree migh
Hm - causing a problem for directories, or where?
It's the shell scripts that need an explicit sh /path/to/script instead just calling /path/to/script
Stefan
On 25.01.2008 20:24, Peter Stuge wrote:
On Fri, Jan 25, 2008 at 07:21:16PM +0100, Stefan Reinauer wrote:
These are very good for distributions. Not all distributions can deal with svn HEAD and few do it well IMO.
What would be the problem with a version "r3065"? I doubt any distributions would have a problem with that.
Yeah, fixed svn rev versions can work like any other versions. I would drop r though, at least Gentoo has a problem with non-numeric versions. (Yes, that sucks.)
Hm yes. Just in case we ever move flashrom to another SVN repository or to another RCS altogether, having a version number as prefix solves the classic upgrade issues. So my suggestion is something like version 0.1.3065 with the svn revision as last part of the version. In case we ever start fresh, we just have to increment the version prefix. We could do that anyway, for example if a new chip/bus type is added.
For the longer term I'd like a config file for flashrom that is all that ever really changes unless a new bus comes along.
ie. describing all the flash chips? I agree.
Not just flash, but also how to reach them. I expect other superios to require different tricks than IT8716, so once we have a few more SPI boards we'll also want to teach flashrom which mainboard uses which superio. (By re-using information from coreboot.) Ideally flashrom would then work out whatever it needs to go through the needed hardware on it's own.
Still, for board specific enable routines you either write the enable routines in some script language, thereby degrading flashrom to a parser, or you tell people to upgrade.
I'd like to unconditionally enable the SPI-behind-SuperIO probing, though.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Martin-Éric Racine -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann