Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html
I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?
Thank you.
My plan is to make a higher compatibility version of ELF.
You may be able to call it ELF2.0
Previous thread on binutils
https://sourceware.org/pipermail/binutils/2025-January/138334.html
I'd like to hear your opinion.
Can we once again promise that only modified files need to be recompiled?
On 2025/01/31 17:05, Jonathan Wakely wrote:
On Fri, 31 Jan 2025, 06:50 The Cuthour via Gcc, <mailto:gcc@gcc.gnu.org>> wrote:
Suppose we have the following two classes:
=== Vec.h ===
class Vec {
int x, y, z;
};
=== end Vec.h ===
=== Pix.h ===
Suppose we have the following two classes:
=== Vec.h ===
class Vec {
int x, y, z;
};
=== end Vec.h ===
=== Pix.h ===
class Pix: Vec {
int r, g, b;
};
=== end Pix.h ===
If we add or remove a member variable in class Vec, it requires
recompiling not only Vec.cc but also Pix.cc. I believ
Hi
struct image
{
vec2 pos[2];
std::vector pixels;
};
Now if any of those structs are modified, members added or removed, it would
require recompilation of the whole code that uses it. This is because the
memory offsets to access the fields change and might fall out of the
displacement r
Hi
On 2025/01/31 18:47, Jonathan Wakely wrote:
On Fri, 31 Jan 2025 at 08:28, The Cuthour wrote:
On 2025/01/31 17:05, Jonathan Wakely wrote:
On Fri, 31 Jan 2025, 06:50 The Cuthour via Gcc, mailto:gcc@gcc.gnu.org>> wrote:
Suppose we have the following two classes:
===
Hi
C++ requires constant expressions to be known during compilation, not
at link time.
A constant that is not determined at compile-time is akin to
constructor that is const but not constexpr. While it remains
constant throughout the program, its value is established only
at link-time, not a
And I heard "That's already here. ELF gABI does the same thing."
Anyway I can't implement it myself. I hope wide discussion.
https://gcc.gnu.org/pipermail/gcc/2025-January/245358.html
On 2025/01/08 22:08, Trampas Stern wrote:
Go do it!
Do it so well and with such high quality that no one can
Facts
(1) There's no header files in Java/Rust.
(2) There's cargo in Rust.
I wish
(1) There was no header files also in C/C++.
(2) There was cargo also in C/C++.
2025年7月16日 3:50:19 JST、Andrew Pinski より:
>On Tue, Jul 15, 2025 at 11:37 AM The Cuthour wrote:
>> I understand that GNU Make and
I think Rust's cargo is a de facto standard build system and package manager,
tightly integrated with the language and compiler.
I'm proposing something similar for C and C++:
- cargo-c for C
- cargo-cc for C++
- cargo-s for assembler
Each one would support:
- Detecting all modified fi
2025年7月17日 2:25:44 JST、Basile Starynkevitch より:
>
>The Cuthour wrote to the GCC mailing list
>
>> I understand that GNU Make and C++ Modules address many current challenges
>> with headers and dependency management.
>>
>> But what I'm suggesting is a build+package manager tightly integrated with
You must be AI.
2025年7月16日 5:07:45 JST、Andrew Pinski より:
>On Tue, Jul 15, 2025 at 1:06 PM The Cuthour wrote:
>>
>>
>> Facts
>>
>> (1) There's no header files in Java/Rust.
>> (2) There's cargo in Rust.
>
>Ok, sounds like you want a language that is NOT C. Or you want to
>improve the standard C/
PM
To: The Cuthour
Cc: GCC Mailing List
Subject: Re: GNU cargo
On Mon, Jul 14, 2025, 11:46 PM The Cuthour via Gcc
mailto:gcc@gcc.gnu.org>> wrote:
I think Rust's cargo is a de facto standard build system and package manager,
tightly integrated with the language and compiler.
I'
14 matches
Mail list logo
