[Top][All Lists]
[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.