On Mon, Oct 30, 2023 at 07:02:10PM +0100, Reimar Döffinger wrote: > > On 30 Oct 2023, at 10:07, gz8...@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 _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel