[PATCH] remove pidl check-clean-tree check from autobuild

Andrew Bartlett abartlet at samba.org
Sun May 26 20:44:04 MDT 2013


On Mon, 2013-05-27 at 03:20 +0200, jelmer at samba.org wrote:
> On Sun, May 26, 2013 at 07:44:13PM +1000, Andrew Bartlett wrote:
> > On Thu, 2013-05-23 at 18:05 +0200, jelmer at samba.org wrote:
> > > On Thu, May 23, 2013 at 09:57:22PM +1000, Andrew Bartlett wrote:
> > > > On Thu, 2013-05-23 at 13:23 +0200, jelmer at samba.org wrote:
> > > > > On Thu, May 23, 2013 at 01:44:06PM +1000, Andrew Bartlett wrote:
> > > > > > I've been testing the remove-autoconf branch, and I hit up against this
> > > > > > issue.  On Fedora 18, I just can't do an autobuild locally until I
> > > > > > remove this check-clean-tree check.
> > > > > > 
> > > > > > I think it's safe to remove, because while the script talks about
> > > > > > uncommited changes, the way autobuild works it only sees real commits.
> > > > > > What it does find (very well) is additional or changed files generated
> > > > > > by the build process in the source tree, ABI files in particular.
> > > > > > 
> > > > > > In pidl, we re-generate with yapp some files, but we do it in place.
> > > > > > Sadly something has changed, and the output order has changed.  I can't
> > > > > > just commit the result, because others would get the error as it changes
> > > > > > back (the old commited configure script issue).  So I think the best
> > > > > > thing is to remove this check from autobuild, for pidl ONLY.
> > > > > > 
> > > > > > Comments and better suggestions welcome, as is review/push if this is
> > > > > > the best approach.
> > > > > Dropping this test means dropping out of tree build support. Do we really want
> > > > > to do that?
> > > > 
> > > > I'm confused.  The reason it's tripping up is that it I get the attached.
> > > > 
> > > > I think that happens because the autobuild is being done in-tree.
> > > Yes, but this check is there so that we don't rely on being able to change the source
> > > tree when building. If we remove it, we're bound to regress that support at some
> > > point.
> > 
> > Isn't that exactly the problem?  We do change this in-tree, but up until
> > now all build hosts have agreed on what the file contents is?
> 
> Yes, that is the fundamental problem we should fix. We shouldn't be changing 
> that file in-tree.

OK.

> I think that's a fixable problem, and not worth killing out-of-tree build support for.

OK.

> If I remember correctly, the old build system would only regenerate this file 
> if the user *explicitly* asked for it. That would also prevent spurious changes
> in git since the output of this process is not deterministic.
> 
> > > If we don't have a way to prevent this file from changing, can we just add
> > > an exception in the check-clean-tree script?
> > Can you see a practical way to have script/clean-source-tree.sh do that?
> > The way it invokes git seems entirely unsuited to additional exceptions
> > other than via .gitignore, and that seems entirely wrong.
> .gitignore doesn't seem like a bad location for this actually. That means
> that if you regenerate this file, "git add" won't add it to the index unless
> you specify -f. That seems like a good way to avoid unnecessary churn, too.

I'll investigate this approach.  Thanks for the input!

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list