On Wednesday 29 August 2007 8:59:32 am Gregg Reynolds wrote: > On 8/28/07, Rob Landley <[EMAIL PROTECTED]> 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. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
