tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] cygwin build


From: Rob Landley
Subject: Re: [Tinycc-devel] cygwin build
Date: Wed, 29 Aug 2007 20:53:45 -0500
User-agent: KMail/1.9.6

On Wednesday 29 August 2007 8:59:32 am Gregg Reynolds wrote:
> On 8/28/07, Rob Landley <address@hidden> wrote:
> > I just yanked the ucontext.h include.  Let me know when you've got a
> > patch for the other two...
>
> Ok, I have a patch, but it's a bit more ambitious.  I have:
>
>   * stripped Makefile and configure to the bare minimum necessary to
> make it go on cygwin

Does this impact any other platforms?

>   * revamped the install stuff to conform with gnu standards. 

I'm having trouble with "gnu" and "standards" existing in the same sentence...

>   Put 
> tcc-specific headers (stddef.h, etc) in PREFIX/lib/tcc/include.

I'm trying to remember a time when I made systems that _didn't_ symlink /lib 
to /usr/lib...  (And /bin to /usr/bin, and /sbin to /usr/sbin...)

I have a rant about that:
http://landley.net/code/firmware/design.html

See "simplifying the $PATH"...

> They're private to tcc, so they don't belong in the user-visible
> include directories.

There are parts of your filesystem that aren't user-visible?  Huh...

When I #include <stdio.h> this isn't private to libc?  Then why is #include 
<stddef.h> private to tcc?  If I, as a programmer, want to read the header 
file to see what the heck it's doing, what's the benefit of making it hard to 
find?

(When did user-visible become a bad thing?)

> This might require some tweaking of tcc to look 
> there first; I haven't tested this out yet, just set up the structure.
>  This is how gcc does it on cygwin;

If "how gcc does it" wasn't often a bad example, tcc wouldn't be nearly as 
interesting...

>  I had a hell of a time finding 
> stddef.h.

I think I used "find / -name stddef.h 2>/dev/null | grep -i tcc" the first 
time...

> This is part of the larger portability issue of tcc's 
> relation to various c std libs, to be addressed in a separate message.

ok

>   * migrated feature tests from bcheck.c to a new file, platform.h,
> that gets included in config.h.  Specifically, the stuff involving
> CONFIG_TCC_MALLOC_HOOKS.  I changed that name to HAVE_MALLOC_HOOKS,
> and test and set it in platform.h.

Sounds reasonable...

>   * migrated feature tests for strtold etc from tcc.h to platform.h
>
>   * migrated into platform.h conditional preproc code from tcc.h involving
>      TCC_TARGET_I386
>      CONFIG_TCC_BCHECK
>      CONFIG_TCC_STATIC
>      CONFIG_TCC_ASM
>      TCC_TARGET_COFF
>
>    and renamed CONFIG_TCC_BCHECK to HAVE_BCHECK (changes in tcc.c,
> tccelf.c, tcctok.c, i386/i386gen.c, etc.)
>
> I think the easiest thing to do might be for you to create branches
> for each platform.  I've got tinycc-cygwin, tinycc-mingw, tinycc-obsd,
> tinycc-osx, and tinycc-fbsd.  If I could clone those from your master
> repository it might be easier to work with for testing and
> experimenting.

Mercurial doesn't work that way.  It's a fully distributed source control 
system, you can create any branches you want, you don't need my help. :)

I can dig up a good primer on distributed source control if you'd like.  I 
remember reading some OLS papers about it...

> Whaddya think?

I think there's no patch attached to this message, but it sounds large and 
non-orthogonal, and I'm worried about its impact on other platforms.  But I 
look forward to reviewing it.

> -gregg

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.




reply via email to

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