Announcing: ZFS-fuse 0.7.0
#62 — SCons caching fails to honor compile flags
| State | Resolved |
|---|---|
| Version: | 0.6.9 |
| Area | Process |
| Issue type | Bug |
| Severity | Low |
| Submitted by | Seth Heeren |
| Submitted on | Jun 15, 2010 |
| Responsible | Seth Heeren |
| Target release: |
—
|
Last modified on
Jun 15, 2010
by
Seth Heeren
On Tue, Jun 15, 2010 at 04:05:28PM +0200, Seth Heeren wrote:
> > On 06/15/2010 03:58 PM, Mike Hommey wrote:
>> > > It's obliterated on *clean*. Any decent build system should leave the
>> > > directory in the same state as it was after unpacking the upstream
>> > > tarball when doing "make clean", or here, the scons equivalent.
>> > >
> > I think that would be dist-clean, or the scons equivalent, scons -ccc;
> >
> > Scons does other things (about speeding up compiles), which would be the
> > equivalent of running ccache/ccontrol on your regular make project.
Note that it does so pretty badly. Contrary to ccache, it doesn't care
about the flags given to the compiler... running scons -c and then scons
with a optim value different from the previous one didn't trigger a new
build on my several tries.
My personal conclusion from the little I used scons is that it's even
crappier than autoconf/automake, which I would have thought hard to
achieve.
Mike
> > On 06/15/2010 03:58 PM, Mike Hommey wrote:
>> > > It's obliterated on *clean*. Any decent build system should leave the
>> > > directory in the same state as it was after unpacking the upstream
>> > > tarball when doing "make clean", or here, the scons equivalent.
>> > >
> > I think that would be dist-clean, or the scons equivalent, scons -ccc;
> >
> > Scons does other things (about speeding up compiles), which would be the
> > equivalent of running ccache/ccontrol on your regular make project.
Note that it does so pretty badly. Contrary to ccache, it doesn't care
about the flags given to the compiler... running scons -c and then scons
with a optim value different from the previous one didn't trigger a new
build on my several tries.
My personal conclusion from the little I used scons is that it's even
crappier than autoconf/automake, which I would have thought hard to
achieve.
Mike
Added by
Seth Heeren
on
Jun 15, 2010 05:22 PM
Issue state:
unconfirmed → resolved
Severity:
Important → Low
It seems to me that you might blame he cache for actually working (and remember different cached configurations ocrrectly, which humans forget).
Since I have detected a healthy developer paranoia in you (I have that too), I have taken the time to painstakenly dissect this issue. I have created a brand new Squeeze installation, and put scons (on zfs-fuse) through every torturous test I could think of (including replacing /usr/bin/gcc by a symlink to it, touching source files or the /usr/bin/gcc binary, even appending a few random bytes to /usr/bin/gcc to make sure that the file is actually _different_).
I have also demonstrated that when 'older' (not the most recent) builds are retrieved from cache, scons is actually serving up the right object files (md5sum verified this) at step 8a
In all sequences, SCons has been doing exactly the right thing. The most important source of confusion was me, sitting behind the keyboard: it is easy to forget what the compiler already did build.
I herewith declare this issue as dealt with.
- The analysis notes are attached
- Terminal script files (http://zfs-fuse.net/wiki/test-results-for-issue-62/view , instructions included)
- If you're particularly masochistic (or paranoid), go see the movie: http://zfs-fuse.s3.amazonaws.com/issue61
You can download the screencast for easier access, even renaming my braindamaged filename on the fly:
curl http://zfs-fuse.s3.amazonaws.com/issue61 > issue62.ogg
That's an ogg vid (no sound). It contains the gory details, including live written comments and the installation phase.
Since I have detected a healthy developer paranoia in you (I have that too), I have taken the time to painstakenly dissect this issue. I have created a brand new Squeeze installation, and put scons (on zfs-fuse) through every torturous test I could think of (including replacing /usr/bin/gcc by a symlink to it, touching source files or the /usr/bin/gcc binary, even appending a few random bytes to /usr/bin/gcc to make sure that the file is actually _different_).
I have also demonstrated that when 'older' (not the most recent) builds are retrieved from cache, scons is actually serving up the right object files (md5sum verified this) at step 8a
In all sequences, SCons has been doing exactly the right thing. The most important source of confusion was me, sitting behind the keyboard: it is easy to forget what the compiler already did build.
I herewith declare this issue as dealt with.
- The analysis notes are attached
- Terminal script files (http://zfs-fuse.net/wiki/test-results-for-issue-62/view , instructions included)
- If you're particularly masochistic (or paranoid), go see the movie: http://zfs-fuse.s3.amazonaws.com/issue61
You can download the screencast for easier access, even renaming my braindamaged filename on the fly:
curl http://zfs-fuse.s3.amazonaws.com/issue61 > issue62.ogg
That's an ogg vid (no sound). It contains the gory details, including live written comments and the installation phase.
analysis.notes
—
Octet Stream,
2Kb
