Re: Help needed with maintainer-mode
On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
> >
> > Hi Christophe,
> >
> > On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
> > > I've noticed that sourceware's buildbot has a small script
> > > "autoregen.py" which does not use the project's build system, but
> > > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
> > > Should we replicate that?
> >
> > That python script works across gcc/binutils/gdb:
> > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
> >
> > It is installed into a container file that has the exact autoconf and
> > automake version needed to regenerate the autotool files:
> > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools
> >
> > And it was indeed done this way because that way the files are
> > regenerated in a reproducible way. Which wasn't the case when using
> > --enable-maintainer-mode (and autoreconfig also doesn't work).
>
> I see. So it is possibly incomplete, in the sense that it may lack
> some of the steps that maintainer-mode would perform?
> For instance, gas for aarch64 has some *opcodes*.c files that need
> regenerating before committing. The regeneration step is enabled in
> maintainer-mode, so I guess the autoregen bots on Sourceware would
> miss a problem with these files?
>
> Thanks,
>
> Christophe
Speaking of opcodes/aarch64-{asm|dis|opc}-2.c - why are these in the source
directory in the first place? For a similar situation in GCC (gimple-match,
generic-match, insn-emit, etc.) we write the generated files to the build
directory, and generation is always enabled. I see no reason not to do the
same thing for aarch64-{asm|dis|opc}-2.c.
Andrew
> >
> > It is run on all commits and warns if it detects a change in the
> > (checked in) generated files.
> > https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
> > https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen
> >
> > Cheers,
> >
> > Mark
Re: Help needed with maintainer-mode
On 06/03/2024 15:04, Andrew Carlotti via Gcc wrote:
> On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
>> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
I've noticed that sourceware's buildbot has a small script
"autoregen.py" which does not use the project's build system, but
rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
Should we replicate that?
>>>
>>> That python script works across gcc/binutils/gdb:
>>> https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
>>>
>>> It is installed into a container file that has the exact autoconf and
>>> automake version needed to regenerate the autotool files:
>>> https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools
>>>
>>> And it was indeed done this way because that way the files are
>>> regenerated in a reproducible way. Which wasn't the case when using
>>> --enable-maintainer-mode (and autoreconfig also doesn't work).
>>
>> I see. So it is possibly incomplete, in the sense that it may lack
>> some of the steps that maintainer-mode would perform?
>> For instance, gas for aarch64 has some *opcodes*.c files that need
>> regenerating before committing. The regeneration step is enabled in
>> maintainer-mode, so I guess the autoregen bots on Sourceware would
>> miss a problem with these files?
>>
>> Thanks,
>>
>> Christophe
>
> Speaking of opcodes/aarch64-{asm|dis|opc}-2.c - why are these in the source
> directory in the first place? For a similar situation in GCC (gimple-match,
> generic-match, insn-emit, etc.) we write the generated files to the build
> directory, and generation is always enabled. I see no reason not to do the
> same thing for aarch64-{asm|dis|opc}-2.c.
>
GCC supports building a canadian cross, but binutils doesn't. To put them in
the build area would require setting up host compiler as well and I don't think
there's currently enough appetite for doing that extra work.
But every do has its day; maybe the time has come...
R.
> Andrew
>
>>>
>>> It is run on all commits and warns if it detects a change in the
>>> (checked in) generated files.
>>> https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
>>> https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen
>>>
>>> Cheers,
>>>
>>> Mark
Re: GNU Tools Cauldron 2024
On Tue, Mar 5, 2024 at 11:01 PM Bradley M. Kuhn via Gcc wrote: > > Jeremy, David, Carlos, and the GCC Community, > > Jeremy Bennett wrote yesterday: > > We are starting to put together the plans for this year's Cauldron. We > > have a suggested date of 13-15 September, the weekend before LPC. > > > We have not finalized a host for the meeting. If you wish to host, please > > let me, David Edelsohn, Carlos O'Donnell or Jan Hubicka know ASAP. > > During the open session at the of Cauldron in 2023, I offered that Software > Freedom Conservancy could offer hosting for a “Cauldron USA” — in conjunction > with the annual FOSSY (Free and Open Source Software Yearly) conference that > we organize and host in each year in Portland, Oregon, USA. > > There seemed some interest to that. We're just a few days away from > finalizing the date and venue for FOSSY. It's similar to FOSDEM in > that we organize and pay for the venue, handle on-site logistics, and > provide the usual logistics — and then volunteers need to handle review > of talk proposals for the track and be on site to introduce speakers, etc. > > This would be different dates (it's likely to be in mid-to-late northern > hemisphere summer), and in the USA, so it would complement the usual > Cauldron. > > Let me know if any of you are interested in this, and I can put you in touch > with the staff at SFC who orgainze FOSSY. > > Let me know! Hi, I would greatly appreciate a US option, and having it in Portland would be especially convenient for me, as then I could stay with family, so I would like to express my interest in it and would hope that such an option can go forwards > -- > Bradley M. Kuhn - he/them > Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy > > Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
[no subject]
Loadings,.
