tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Understanding tcc Makefile


From: grischka
Subject: Re: [Tinycc-devel] Understanding tcc Makefile
Date: Mon, 07 Dec 2009 23:13:39 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

k1w1 wrote:
    On windows, all objects that tcc wants to use must be compiled
    with tcc itself.  In particular not with mingw-gcc.

How about on other platforms. I was observing this behavior under Cygwin which is more linux-like than anything else.

Cygwin is not supported, neither by the build system, nor by the
code.  It is no surprise that you see strange things happen.

The refactoring I have done so far is basically the minimum necessary to avoid ever #including a .c file.

:D  Not including .c files is one thing, creating more .c files
is something completely different.

Now that I understand the code better I am in a position to understand different code structure alternatives. I am open to suggestions and willing to invest the effort to make the code easier to understand and easier to maintain. However it does seem to me that merging things back into a monolithic structure would run counter to those goals.

Well, you understand it better mostly because you spend some time with
it.  To other peoples the difference is maybe less obvious.

For example I don't understand why tccld.c needs an extra file, or
why tcccstring and tccsym cannot be in utils or why tccargs cannot
be in libtcc or why three tccosxxx cannot be in one file, or why
tccpp/gen/elf/asm.h cannot be in tcc.h, simply.

    Note that we do not support bounds checking on windows currently.
    I don't say it is not possible but it will not work out of the
    box.


I definitely want this feature so I will get it working. However it does seem like it more be better to branch the code into another version for Windows rather than adding yet another layer of #ifdefs to bcheck.c.

In many cases some more #ifdef's in one file are still better than
some more files with almost same code.  Because nobody wants to fix
the same bugs twice.

Regards, k1w1.

--- grischka





reply via email to

[Prev in Thread] Current Thread [Next in Thread]