[PATCH util-modular 6/6] release.sh: run ./configure within the release.sh

Peter Hutterer peter.hutterer at who-t.net
Fri Nov 18 07:06:56 UTC 2016


On Tue, Nov 15, 2016 at 02:13:32PM +0000, Emil Velikov wrote:
> On 14 November 2016 at 20:54, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Mon, Nov 14, 2016 at 03:39:18PM +0000, Emil Velikov wrote:
> >> On 13 November 2016 at 22:24, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >> > On Fri, Nov 11, 2016 at 03:45:29PM +0000, Emil Velikov wrote:
> >> >> From: Emil Velikov <emil.velikov at collabora.com>
> > [...]
> >> >> +        return 1
> >> >>      fi
> >> >> -    build_dir=`dirname $status_file`
> >> >> +
> >> >>      cd $build_dir
> >> >>      if [ $? -ne 0 ]; then
> >> >>       echo "Error: failed to cd to $MODULE_RPATH/$build_dir."
> >> >> @@ -377,6 +373,15 @@ process_module() {
> >> >>       return 1
> >> >>      fi
> >> >>
> >> >> +    # Using ../ here feels a bit nasty, yet $top_src is an absolute path. Thus
> >> >> +    # it will get propagated in the generated sources, which we do not want.
> >> >> +    ../configure >/dev/null
> >> >> +    if [ $? -ne 0 ]; then
> >> >> +        echo "Error: failed to configure module."
> >> >> +        cd $top_src
> >> >
> >> > I'd really like to see more pushd/popd, but that's unrelated to this patch.
> >> > Looks good, but I think you should look at the effort to do a full local
> >> > clone, it may only be a few lines and it should remove quite a bit of the
> >> > error checking.
> >> >
> >> Yes I'm thinking/working towards having things in a cleaner state. At
> >> the same time this patch would cause a noticeable change in workflow,
> >> so I've intentionally opted out of making things too intrusive.
> >>
> >> Any objections against git worktree and/or moving towards it as a
> >> follow-up change ?
> >> Or you'd thinking this patch should be "it's all or nothing" kind of change ?
> >
> > simply said, I don't know enough about worktrees to have an opinion here,
> > sorry. for the mere tarball generation and distcheck run you can use a
> > shallow clone though, can't you? Just something to keep in mind, if the
> > worktree works as a clean checkout without detritus, I'll be happy with tha
> > too.
> >
> In a line: worktree like a fresh clone, with the only difference being
> that .git is a file pointing to the actual git repo.
> Here is an example and more info [1].
> 
> Can we have all that [shallow/full clone, worktree, other] as
> follow-up, please ? Or you really don't like the git clean suggestion

nah, not something I'm going to fight over. I'll push this when I have some
brainspace available again, sorry about the delay.

Cheers,
   Peter


> ?
> The current patch/workflow has been tested for over a dozen times and
> I feel a bit reluctant in pushing for something that's barely tested
> :-\
> 
> Thanks
> Emil
> 
> [1] https://git-scm.com/docs/git-worktree#_examples


More information about the xorg-devel mailing list