Emil I looked at commit 3689ef32 which started the problem, and it seems that patch removed the line "touch git_sha1.h.tmp". Previously my workflow was "working" because the touch command ensures there's always going to be an empty header file.
Was this intentional? For the new git_sha1.h rules, I wonder if it is ok to add a step for git_sha1.h.tmp that does a "touch git_sha1.h" to ensure the file exists? On Thu, Jun 16, 2016 at 12:48 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 16 June 2016 at 20:47, Emil Velikov <emil.l.veli...@gmail.com> wrote: > > On 16 June 2016 at 20:42, Haixia Shi <h...@chromium.org> wrote: > >> Bisect shows the problem started at commit > >> 3689ef32afdafbb030069e560aac0e563fc29048 > >> Author: Emil Velikov <emil.veli...@collabora.com> > >> Date: Mon May 30 12:32:05 2016 +0100 > >> > >> automake: rework the git_sha1.h rule, include in tarball > >> > >> As we'll need the file in the release tarball, rework the rule so > that > >> the file is regenerated _only_ if we're in a git repository. > >> > >> With this in place we can build vulkan (anv) from a release tarball. > >> > >> Cc: Jason Ekstrand <jason.ekstr...@intel.com> > >> Cc: Kristian Høgsberg Kristensen <k...@bitplanet.net> > >> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> > >> > >> I'm not building from a release tarball, but the workflow first copies > the > >> source tree to a tmp directory (without the .git directory), so there's > no > >> git_sha1.h file, and the file is not generated either. > >> > > Hmmm... I wouldn't have imagine this particular workflow. Have you > > considered gitlink and/or git worktree ? > > > > If neither of these are an option for you see my earlier email. > > > The former seems to be missing a manpage so here's a PDF > https://media.readthedocs.org/pdf/git-link/latest/git-link.pdf > > -Emil >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
