Re: One version number, &c, take two

[Zack Weinberg <zack at codesourcery dot com>]

DJ Delorie <dj@redhat.com> writes:

>> > I was thinking about divergent opinions about the tagging process,
>> > not the actual date used.  Binutils already has an alternate
>> > scheme with daily tagging.
>> 
>> Could you expand a bit please?
>
> Binutils uses bfd/version.h for everyone's datestamp.  Adding a second
> datestamp file would make their situation worse, not better.

After some shakeout time in gcc only, presumably they could start
using a similar scheme?  (yes, I would help adapt scripts and
makefiles as necessary.)

>> > The toplevel config/* is currently manually sync'd between gcc and
>> > binutils, it would be a mess if that blew up my scripts.
>> 
>> It's just the one file, could you special-case it?
>
> Not easily.  The script works by inclusion; currently I include
> ./config.  To exclude one file, I'd have to manually list (and
> maintain the list of) every other file in ./config/*.
>
> Could you commit to both repositories, so that the file stays in sync?

I'm not sure if I understand the requirement here.  Would it be
necessary for the nightly GCC cron job to commit the file to each
repository on every bump?  Or can I just create the file the first
time and let your sync scripts propagate the nightly bumps?

What about the other files, which change occasionally?

>> In my opinion, only files specific to the gcc program belong in the
>> gcc subdirectory.
>
> Yet, you're planning on putting something that's not globally used in
> a global directory.  Too bad we don't have an in-between solution;
> something that's common to all the gcc components but separate from
> binutils and gdb.  The gcc subdirectory used to be that.

I honestly don't see the problem here.  There is lots of stuff in
toplevel, config, and include that is only relevant to a subset of the
projects in src+gcc.

zw