linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl@jdl.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: DTC 1.0.0 Release Coming?
Date: Thu, 26 Jul 2007 10:21:33 -0500	[thread overview]
Message-ID: <E1IE59h-0001tt-JE@jdl.com> (raw)
In-Reply-To: Your message of "Fri, 27 Jul 2007 00:27:39 +1000." <20070726142739.GB18684@localhost.localdomain>

So, like, the other day David Gibson mumbled:

> > > Only thing I'm not really happy with in the current release is the
> > > versioning stuff.  For starters, it always reports my builds as
> > > -dirty, even when they're not.
> > 
> > I think it won't do that once there is a tag available.
> 
> Your 1.0.0-rc1 tag is there, still showing as dirty.

Hmmm.. Seems to work here.  Is your working directory really clean?

    jdl.com 872 % make clean
	     CLEAN (libfdt)
	     CLEAN (tests)
	     CLEAN
    jdl.com 873 % make
	     LEX lex.yy.c
	     BISON dtc-parser.tab.c
	     ---- Expect 2 s/r and 2 r/r. ----
    dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce
	    CHK version_gen.h
	    UPD version_gen.h
	     CC dtc.o
	     CC flattree.o
	[ snip ]
	     CC tests/del_node.o
	     CC tests/truncated_property.o
	     AS tests/trees.o
	     DUMPTREES
    jdl.com 874 % ./dtc -v
    Version: DTC 1.0.0-rc1


I hve also verified that at least one other independent build
using this approach produces a correct version string for them
as well.


> > That is essentially what is there now.  We just need a tag!
> 
> Um... no.  The base version comes from the numbers specified in the
> Makefile, not from the git tag.

Ah, ok.  I understand what you mean now.  That part.
So run it the other way instead.  So perhaps have the
Makefile generate the tag using those versioning parts
instead using some "make tagged_release" target?

> > I would like to keep the current version mechanism as it
> > is really quite similar to what is in the Kernel now.
> 
> First, I don't think it really is - except in superficial aspect of
> how the version number is partitioned

I lifted the code from the Kernel's Makefile directly, and tweaked
it slightly for lack of Kconfig aspects.

I don't want to tie the code and build mechanism to git too much.
Specifically, we need to be able to support stand-alone tarball
based builds.  For example, I've spoken to the Debian package
maintainer on this issue, and he likes this approach as well as
he says it will make packaging it much easier.

*sigh*

jdl

  reply	other threads:[~2007-07-26 15:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-25 16:12 DTC 1.0.0 Release Coming? Jon Loeliger
2007-07-26  3:05 ` David Gibson
2007-07-26  7:25   ` David Gibson
2007-07-26 13:04   ` Jon Loeliger
2007-07-26 14:27     ` David Gibson
2007-07-26 15:21       ` Jon Loeliger [this message]
2007-07-27  1:33         ` David Gibson
2007-07-27  2:00           ` David Gibson
2007-07-31 21:11             ` Segher Boessenkool
2007-08-01  1:19               ` David Gibson
2007-08-06 19:33                 ` Segher Boessenkool
2007-08-06 13:48           ` Josh Boyer
2007-08-10  1:30             ` David Gibson
2007-08-10  1:37               ` Josh Boyer
2007-08-10  2:59                 ` David Gibson
2007-08-10 20:59                   ` Segher Boessenkool
2007-08-10 22:24                     ` Geoff Levand
2007-08-10 23:39                       ` Segher Boessenkool
2007-08-11  0:52                   ` Paul Mackerras
2007-08-11  1:35                     ` Geoff Levand
2007-08-12  9:26                       ` David Gibson
2007-08-13  1:39                         ` Stephen Rothwell
2007-08-12  9:25                     ` David Gibson
2007-08-10  2:13               ` Geoff Levand
2007-07-31 21:09 ` Segher Boessenkool
2007-08-01 23:35 ` Arnd Bergmann
2007-08-02  0:14   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1IE59h-0001tt-JE@jdl.com \
    --to=jdl@jdl.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).