From: Jon Loeliger <hidden> Date: 2007-07-26 15:21:33
So, like, the other day David Gibson mumbled:
quoted
quoted
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.
quoted
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?
quoted
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
From: David Gibson <hidden> Date: 2007-07-27 01:33:31
On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
So, like, the other day David Gibson mumbled:
quoted
quoted
quoted
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?
Yes, it really is. I have quilt control directories, but it still
shows as dirty with no patches applied. Exttra files which don't
affect the build shouldn't count as being dirty.
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.
Yes, well, this is the other trouble - the current system is so
complex it's very hard to debug and figure out why it's claiming my
build is dirty but not yours.
quoted
quoted
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?
Hrm... I really think the other way is both easier and less fragile.
quoted
quoted
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.
Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff
makes much sense outside the context of Kbuild. The whole complex
filechk macro, for example - for which there's only one used parameter
in dtc's case.
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.
Have a look at the patch I posted. I haven't sufficiently tested it
yet, but it should be able to generated version info for a tarball too
(provided the .git-manifest file is included, and I'm intending that
will be build by a make dist target). It will give both the
git-derived based version, and a file content derived hash so we can
robustly tell different builds apart, all with less code than the
current system.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-07-27 02:00:41
On Fri, Jul 27, 2007 at 11:33:31AM +1000, David Gibson wrote:
On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
[snip]
quoted
I hve also verified that at least one other independent build
using this approach produces a correct version string for them
as well.
Yes, well, this is the other trouble - the current system is so
complex it's very hard to debug and figure out why it's claiming my
build is dirty but not yours.
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or gitool or various other things causes git to
notice that the files aren't really changed, updates the index and
then the version is generated correctly again.
Not very robust though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or gitool or various other things causes git to
notice that the files aren't really changed, updates the index and
then the version is generated correctly again.
Not very robust though.
Well you can't blame that on DTC's build system, nor on the
setlocalversion script, and not on Git either; it's a Quilt
problem...
Segher
From: David Gibson <hidden> Date: 2007-08-01 01:19:00
On Tue, Jul 31, 2007 at 11:11:57PM +0200, Segher Boessenkool wrote:
quoted
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or gitool or various other things causes git to
notice that the files aren't really changed, updates the index and
then the version is generated correctly again.
Not very robust though.
Well you can't blame that on DTC's build system, nor on the
setlocalversion script, and not on Git either; it's a Quilt
problem...
No, it's really not - touching the files on a pop is correct behaviour
for quilt (that way it will correctly trigger a rebuild on make
systems that aren't as flashy as Kbuild).
setlocalversion should be ensuring that the verison information is
based on content, not stat info, which means it needs to do a git
status or something that will remove the false positives before using
git-diff-index to determine whether the tree is clean or not.
But I still think my approach of basing the version info directly off
a hash or the source is nicer still.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Ok, figured out why. When I push, then pop a quilt patch some of the
files end up with their original contents, but changed timestamps.
That altered stat information causes git-diff-index to give false
indications of changed files, so setlocalversion adds the -dirty.
Running git status, or gitool or various other things causes git to
notice that the files aren't really changed, updates the index and
then the version is generated correctly again.
Not very robust though.
Well you can't blame that on DTC's build system, nor on the
setlocalversion script, and not on Git either; it's a Quilt
problem...
No, it's really not - touching the files on a pop is correct behaviour
for quilt (that way it will correctly trigger a rebuild on make
systems that aren't as flashy as Kbuild).
Yeah okay -- "it's a problem with how all these tools are used
together" :-)
setlocalversion should be ensuring that the verison information is
based on content, not stat info, which means it needs to do a git
status or something that will remove the false positives before using
git-diff-index to determine whether the tree is clean or not.
Yeah, that seems best. Please fix this for the kernel version of
setlocalversion as well :-)
Segher
On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson [off-list ref] wrote:
On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
quoted
So, like, the other day David Gibson mumbled:
quoted
quoted
quoted
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.
git vs quilt issue, as you have already discovered. I've always seen
that with kernel builds.
quoted
quoted
quoted
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.
Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff
makes much sense outside the context of Kbuild. The whole complex
filechk macro, for example - for which there's only one used parameter
in dtc's case.
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
quoted
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.
Have a look at the patch I posted. I haven't sufficiently tested it
yet, but it should be able to generated version info for a tarball too
(provided the .git-manifest file is included, and I'm intending that
will be build by a make dist target). It will give both the
git-derived based version, and a file content derived hash so we can
robustly tell different builds apart, all with less code than the
current system.
That may be. But I don't see the current approach being too much of a
problem either. Especially given that it's already there and it
works. Oh, and you sent out your patch saying it wasn't ready for
merge and with no sign off. Small but important issues to fix I'd
think.
This seems to be the last issue holding up a dtc 1.0 release. Perhaps
we could go with what exists and see if there really are problems. It
can always be fixed later.
josh
From: David Gibson <hidden> Date: 2007-08-10 01:32:40
On Mon, Aug 06, 2007 at 08:48:13AM -0500, Josh Boyer wrote:
On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson [off-list ref] wrote:
quoted
On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
quoted
So, like, the other day David Gibson mumbled:
quoted
quoted
quoted
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.
git vs quilt issue, as you have already discovered. I've always seen
that with kernel builds.
Yeah, ick.
quoted
quoted
quoted
quoted
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.
Ah, yes, ok, I see. Frankly I really don't think a lot of that stuff
makes much sense outside the context of Kbuild. The whole complex
filechk macro, for example - for which there's only one used parameter
in dtc's case.
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus, we decided not to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
quoted
quoted
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.
Have a look at the patch I posted. I haven't sufficiently tested it
yet, but it should be able to generated version info for a tarball too
(provided the .git-manifest file is included, and I'm intending that
will be build by a make dist target). It will give both the
git-derived based version, and a file content derived hash so we can
robustly tell different builds apart, all with less code than the
current system.
That may be. But I don't see the current approach being too much of a
problem either. Especially given that it's already there and it
works. Oh, and you sent out your patch saying it wasn't ready for
merge and with no sign off. Small but important issues to fix I'd
think.
Yeah, it lacks a make dist target, and needs a bit more work to
support that properly. Never mind, I'll revisit this post the 1.0
release.
This seems to be the last issue holding up a dtc 1.0 release. Perhaps
we could go with what exists and see if there really are problems. It
can always be fixed later.
josh
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Fri, 10 Aug 2007 11:30:01 +1000
David Gibson [off-list ref] wrote:
quoted
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus, we decided not to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
Can you elaborate why you decided not to? I'm just curious.
quoted
quoted
Have a look at the patch I posted. I haven't sufficiently tested it
yet, but it should be able to generated version info for a tarball too
(provided the .git-manifest file is included, and I'm intending that
will be build by a make dist target). It will give both the
git-derived based version, and a file content derived hash so we can
robustly tell different builds apart, all with less code than the
current system.
That may be. But I don't see the current approach being too much of a
problem either. Especially given that it's already there and it
works. Oh, and you sent out your patch saying it wasn't ready for
merge and with no sign off. Small but important issues to fix I'd
think.
Yeah, it lacks a make dist target, and needs a bit more work to
support that properly. Never mind, I'll revisit this post the 1.0
release.
From: David Gibson <hidden> Date: 2007-08-10 03:07:12
On Thu, Aug 09, 2007 at 08:37:54PM -0500, Josh Boyer wrote:
On Fri, 10 Aug 2007 11:30:01 +1000
David Gibson [off-list ref] wrote:
quoted
quoted
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus, we decided not to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
Can you elaborate why you decided not to? I'm just curious.
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement, rather than
integrate the substantial blob of dtc code into the kernel tree and
then have to deal with the maintenance / synchronization issues
between the in-kernel and upstream versions.
quoted
quoted
quoted
Have a look at the patch I posted. I haven't sufficiently tested it
yet, but it should be able to generated version info for a tarball too
(provided the .git-manifest file is included, and I'm intending that
will be build by a make dist target). It will give both the
git-derived based version, and a file content derived hash so we can
robustly tell different builds apart, all with less code than the
current system.
That may be. But I don't see the current approach being too much of a
problem either. Especially given that it's already there and it
works. Oh, and you sent out your patch saying it wasn't ready for
merge and with no sign off. Small but important issues to fix I'd
think.
Yeah, it lacks a make dist target, and needs a bit more work to
support that properly. Never mind, I'll revisit this post the 1.0
release.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Actually, after discussions with Stephen and Paulus, we decided not
to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
Can you elaborate why you decided not to? I'm just curious.
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement,
For _all_ kernel builds? Most people building a powerpc
kernel don't need it.
Segher
Actually, after discussions with Stephen and Paulus, we decided not
to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
Can you elaborate why you decided not to? I'm just curious.
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement,
For _all_ kernel builds? Most people building a powerpc
kernel don't need it.
The dtc is run from the wrapper script, so if you build for a platform
that uses a dts source file, then you'll need the dtc. If you don't
build for one of those platforms, then you won't needed it.
So a 'make allXXXconfig' needs the dtc to be installed since it
builds platforms that use dts source files.
-Geoff
From: Paul Mackerras <hidden> Date: 2007-08-11 00:52:07
David Gibson writes:
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement, rather than
integrate the substantial blob of dtc code into the kernel tree and
then have to deal with the maintenance / synchronization issues
between the in-kernel and upstream versions.
Um, what I thought we decided was to ship a pre-built .dtb for ps3
(once its dts settles down), and make dtc a kernel build requirement
only for embedded platforms.
Paul.
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement, rather than
integrate the substantial blob of dtc code into the kernel tree and
then have to deal with the maintenance / synchronization issues
between the in-kernel and upstream versions.
Um, what I thought we decided was to ship a pre-built .dtb for ps3
(once its dts settles down), and make dtc a kernel build requirement
only for embedded platforms.
We could also ship a generated .S file (dtc -O asm -o ps3-dt.S ps3.dts),
which would be easier to maintain in the source tree than a binary file,
then use something like this in the wrapper script:
${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S
${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb
Untested, but it seems like it would work.
-Geoff
From: David Gibson <hidden> Date: 2007-08-13 01:20:37
On Fri, Aug 10, 2007 at 06:35:46PM -0700, Geoff Levand wrote:
Paul Mackerras wrote:
quoted
David Gibson writes:
quoted
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement, rather than
integrate the substantial blob of dtc code into the kernel tree and
then have to deal with the maintenance / synchronization issues
between the in-kernel and upstream versions.
Um, what I thought we decided was to ship a pre-built .dtb for ps3
(once its dts settles down), and make dtc a kernel build requirement
only for embedded platforms.
We could also ship a generated .S file (dtc -O asm -o ps3-dt.S ps3.dts),
which would be easier to maintain in the source tree than a binary file,
then use something like this in the wrapper script:
${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S
${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb
Untested, but it seems like it would work.
Yes, I'm aware of that option and am considering it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Stephen Rothwell <hidden> Date: 2007-08-13 01:39:59
On Sun, 12 Aug 2007 19:26:27 +1000 David Gibson [off-list ref] wrote:
On Fri, Aug 10, 2007 at 06:35:46PM -0700, Geoff Levand wrote:
quoted
We could also ship a generated .S file (dtc -O asm -o ps3-dt.S
ps3.dts), which would be easier to maintain in the source tree than a
binary file, then use something like this in the wrapper script:
${CROSS}gcc -c -o ${platform}-dt.o ${platform}-dt.S
${CROSS}objcopy -O binary ${platform}-dt.o ${platform}.dtb
Untested, but it seems like it would work.
Yes, I'm aware of that option and am considering it.
Seems like a better option than a binary blob ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: David Gibson <hidden> Date: 2007-08-13 01:20:39
On Sat, Aug 11, 2007 at 10:52:07AM +1000, Paul Mackerras wrote:
David Gibson writes:
quoted
We decided that since a formal dtc release was imminent, it would be
simpler to make dtc a new kernel build requirement, rather than
integrate the substantial blob of dtc code into the kernel tree and
then have to deal with the maintenance / synchronization issues
between the in-kernel and upstream versions.
Um, what I thought we decided was to ship a pre-built .dtb for ps3
(once its dts settles down), and make dtc a kernel build requirement
only for embedded platforms.
Oh, yes, sorry forgot that detail.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus, we decided not to
take this route.
Could you please let us know what was discussed, and what was proposed to
solve the problem of build failures when dtc is not installed?
-Geoff