On 8/24/22 15:51, Philip Herron wrote:
> Hi Martin,
>
> Not right now, it is on the to-do list, but do we have to do it in texinfo?
Well, I still hope we will move to Sphinx (and remove Texinfo) after the
Cauldron.
Anyway, using Sphinx is even now possible as a default documentation formal
(see
Hi Martin,
Not right now, it is on the to-do list, but do we have to do it in texinfo?
Thanks
--Phil
On Wed, 24 Aug 2022 at 14:49, Martin Liška wrote:
>
> On 8/15/22 16:33, Martin Liška wrote:
> > On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
> >> Dear Philip,
> >>
> >> Another
On 8/15/22 16:33, Martin Liška wrote:
> On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
>> Dear Philip,
>>
>> Another thing to pay attention to is the move to Sphinx for documentation:
>> https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
>
> Hi.
>
> Which is something I can h
On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
> Dear Philip,
>
> Another thing to pay attention to is the move to Sphinx for documentation:
> https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
Hi.
Which is something I can help you with. I have a script that converts a texin
Dear Philip,
Another thing to pay attention to is the move to Sphinx for documentation:
https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
Best,
Manuel.
On Wed, 10 Aug 2022 at 20:57, Philip Herron
wrote:
> Hi everyone
>
> For my v2 of the patches, I've been spending a lot of time ensur
On Aug 10, 2022, at 11:56 AM, Philip Herron wrote:
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end in more patches.
On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote:
> Hi everyone
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end
Hi everyone
For my v2 of the patches, I've been spending a lot of time ensuring
each patch is buildable. It would end up being simpler if it was
possible if each patch did not have to be like this so I could split
up the front-end in more patches. Does this make sense? In theory,
when everything g
Thanks, for confirming David. I think it was too big in the end. I was
trying to figure out how to actually split that up but it seems
reasonable that I can split up the front-end patches into patches for
each separate pass in the compiler seems like a reasonable approach
for now.
--Phil
On Wed,
On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
wrote:
> This is the initial version 1 patch set for the Rust front-end. There
> are more changes that need to be extracted out for all the target
> hooks we have implemented. The goal is to see if we are implementing
> the target
10 matches
Mail list logo
