[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] [PATCH] Add support for reading thin archive files.
From: |
gz8cx4 |
Subject: |
Re: [Tinycc-devel] [PATCH] Add support for reading thin archive files. |
Date: |
Tue, 31 Oct 2023 10:06:36 +0100 |
On Mon, Oct 30, 2023 at 07:02:10PM +0100, Reimar Döffinger wrote:
> > On 30 Oct 2023, at 10:07, gz8cx4@0w.se wrote:
> > This looks to me like bugs in the corresponding projects?..
> > (we shouldn't put code into tcc to work around someone else's *bugs*)
>
> Checking for every single possible thing in the build system isn't
> very sensible either.
Not "every possible thing", but a feature a project explicitly decides to
depend upon. This _is_ a bug if they do not check.
> How far does tcc want to go in aligning with mainstream compilers?
A good question.
> A similar example is that tcc exits when specifying -l with -c,
> is it strictly correct? Yes.
> Does it make sense? It seems like it makes it hard to compile existing
> programs using tcc for no real benefit.
I find it hard to accept this example, it looks like *guessing*
what the user might have meant with the contradictory command line.
Regarding a "real benefit" - there is a real benefit, which is
to keep tcc small and minimally complex.
> Not sure if there is a project vision here on what the goal is?
What comes to my mind are the first two qualities listed
on https:/bellard.org/tcc
"
SMALL! You can compile and execute C code everywhere, for example on rescue
disks (about 100KB for x86 TCC executable, including C preprocessor, C
compiler, assembler and linker).
FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link
several times faster than GCC.
"
as well as grishka's notice
in https://lists.nongnu.org/archive/html/tinycc-devel/2023-06/msg00024.html
"
tinycc does have a mission that gcc does not have, which is to be
fast and simple.
"
This corresponds well to what I appreciate in Tiny CC.
Use of thin archives apparently does make certain build variations
faster, but this is not what I personally would suggest to trade extra
complexity for.
Others' usage scenarios and preferences can very well be different.
That's why it is so useful to talk.
> Also, someone needs to write and maintain the documentation, and
A very good point.
> as of now the documentation does not even have a section about "porting"
> existing software to tcc.
Yes, it would be useful to document those two kinds of issues:
The tcc differences from the command line language of gcc/binutils which
became [to be widely treated as] a de-facto standard.
A summary of which errors various projects tend to make, affecting tcc,
and how this can be worked around, if bug reporting to the corresponding
project is not an option.
> Anyway this is not something that is super important to me, it just
> seemed something I hoped might be a trivial improvement.
> Which it was not quite, thus why I sent it to the list first :)
I am not opposed to the support of thin archives but suggest caution
before adding code. Your stance is appreciated.
Regards,
/tccm