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 05:05 PM, Pedro Alves wrote:
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.

I misunderstood it, because patch 1/9 is one of the patches "Import unistd and pathmax gnulib modules.", and I never tried removing 'import' directory and run update-gnulib.sh.


>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.


Yes, I can get the patch #1 in my local tree.

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!


Agreed. Otherwise, when we upgrade gnulib to a recent commit, we'll get some unexpected changes in the diff.

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.

So "this" means remove directory 'import', run update-gnulib.sh, and make sure there is no diff in gdb/gnulib, right?


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

Yeah, I can reproduce that.

--
Yao (éå)


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