This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/9] Reimport gnulib from scratch.


On 06/28/2013 09:41 AM, Yao Qi wrote:
> On 06/28/2013 02:52 AM, Pedro Alves wrote:
>> I tried moving aside gnulib/import/, and re-running the our
>> gnulib/update-gnulib.sh script, and surprisingly, I get a different
>> result compared to what's in the tree.  This is with pristine FSF
>> autoconf and FSF automake, at the versions required by
>> update-gnulib.sh.  However, if I just run the update-gnulib.sh scripts
>> against the_existing_  tree, then nothing changes...  I suspect
>> gnulib-tool's merge logic might be preserving some things by design.
>> I think we should put this in regardless, as a "get rid of cruft that
>> might have accumulated over gnulib updates".  onceonly.m4 seems to fit
>> in that category.
> 
> Pedro,
> I tried to run update-gnulib.sh to import module unistd, and the result 
> looks right to me.  Don't know why we need to reimport gnulib here. 

You misunderstand.  I never said we _need_ to reimport gnulib in
order to pull in unistd.  This patch is in the series as I based
subsequent patches on top of it.  It isn't strictly necessary,
and we could do this reimporting after the series instead.  Sorry
if that wasn't clear.

> Here are my steps,
> 
> 1. cd to <my gnulib repository> and check out commit.
> 8d5bd1402003bd0153984b138735adf537d960b0, which is required by
> update-gnulib.sh
> 
> 2. Modify update-gnulib.sh to add unistd into IMPORTED_GNULIB_MODULES,
> 
> 3. Run 'bash update-gnulib.sh <my gnulib repository>'.
> 
> Here is the diff of aclocal.m4, for the reference sake.

As you see from your diff, doing things that way preserves
onlyonce.m4.

Now try what I suggested.  Do:

1.1. mv import import.old
1.2. mkdir import
1.3. Run 'bash update-gnulib.sh <my gnulib repository>'.
1.4. Diff the resulting gnulib/ trees.  (or git diff, or whatever)

You'll (I hope) differences similar this patch #1.

At this point, one begins to wonder whether unistd is related.
Then go back to a pristine tree, and do the same exercise,
but without importing unistd:

2.1. Run 'bash update-gnulib.sh <my gnulib repository>'.
2.2. Diff the result, nothing should have changed.
2.2. mv import import.old
2.3. mkdir import
2.4. Run 'bash update-gnulib.sh <my gnulib repository>'.
2.5. Diff the resulting gnulib/ trees.

At 2.5, you should see a diff just like this patch #1.

What I'm saying is that we should be able to generate our gnulib
import from scratch and end up with the exact same as we have
in the tree.  But, if we actually try doing it, we don't!

So this patch proposes getting rid of the cruft gnulib-tool is
leaving behind, and I'm suggesting we should probably be
doing this always.

I'd be interested in knowing if you can reproduce these
results.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]