At Mon, 14 Mar 2011 15:06:30 +0000, Colin Guthrie wrote:
'Twas brillig, and Takashi Iwai at 14/03/11 13:21 did gyre and gimble:
At Mon, 14 Mar 2011 13:16:43 +0000,
When these change, the file alsa-driver/includes/sound/.includes (which is generated by alsa-driver/includes/sound/Makefile) is *not* updated. Therefore, the patch information is bogus and incorrect.
But you did clean up before update, right? "make clean" should remove .includes file.
Hmm, I probably didn't actually. :s
I guess the bisecting process etc. for this repos must be a bit different to other areas? Would I need a full make clean and recompile at each stage of a bisect (not that it takes all that long).
Yes. But bisecting is difficult with the combined tree.
Really the build script needs to rm that file or the Makefile has to be able to update it accordingly.
I also run into the same problem when trying to chase down a regression (a pre-bisect checks). I was not able to rebuild the older drivers easily without rm'ing the above .includes file. Obviously even with the two patches I attached previously, it only papers over the problem as the .include file is simply out of date. Correcting the .include file should avoid the need for my changes.
Am I missing a trick here or is it part of the bi-secting process?
Also please see my other mail about *how* to do a bisect here - while keeping alsa-driver and alsa-kernel in sync....
Use alsa-kmirror.
Hmmm, OK. Any page describing how to do this anywhere? e.g. how to clone, bisect etc. on older versions of the drivers?
It's not trivial because these are basically two individual trees. They aren't always in sync. alsa-driver tree is fixed once when some build errors are detected, for example. So, the only sane way would be to use alsa-kmirror. This is often still not trivial because of build breakage...
Nowadays usually the bisect is done inside the kernel tree.
Takashi