On 8/29/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > 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?
At the moment, yes. I'm tossing the current configure/makefile - the conditional feature setting should go elsewhere, and it doesn't work on non-gnu makes. So I'm starting with a working setup which I'll generalize. An experiment that may or may not be to your liking. > > * revamped the install stuff to conform with gnu standards. > > I'm having trouble with "gnu" and "standards" existing in the same sentence... Try harder. prefix=/usr/local, docs in $(prefix)/share/PKG, etc. You may not like GNU conventions, but they're the closest thing we have to a standard for certain things like this. I think it's safe to assume that most users will expect the usual install directories, for example. > > 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...) Cygwin, remember? It does support some kind of symlink simulation, but I kinda sorta don't trust them, call me paranoid. > > > 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? You got me; ask the cygwin people. Cygwin puts <stddef.h> and a few other files under the /usr/lib/gcc hierarchy, not /usr/include. The stuff in the include dir of the tinycc source tree, plus some others. Dunno why, maybe you can enlighten me. Maybe "visibility" is the wrong term. As to visibility, I believe compilers are free to implement standard headers, so #include <foo.h> turns on a set of definitions in the compiler; in which case there is no header to examine. > > (When did user-visible become a bad thing?) When users became annoying? The same time it became a bad thing to allow my cat to see a glass of water (i.e. when she decided such glasses had to be toppled.) > > 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... Sure, take the easy way out! I refuse on principle to run find on /. ;) gcc -H worked, once I knew -H was there. > > > > 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 Sure it does, if you want it to. You clone the master source to a tinycc-cygwin branch, I (and anybody else) clone from the branch and push changes back to it. Everything nice and segregated until you decide it's worth merging into the master. Branch-as-communication-channel. Or am I missing something? I understand distributed vc (I think), but I admit I have quite limited practical experience managing changesets. > system, you can create any branches you want, you don't need my help. Whatever is easiest for you. I was thinking that the changes I'm working on will change the look of the source tree sufficiently that you might want to keep it on a side branch for a while. I can make local branches, but I can only push them back to you on the main branch, no? If that's your preference let me know. In any case, my changes are really of two sorts: one to get it going in cygwin, the other to reorg things a bit to improve portability or at least clarity in the source. It's compiling on cygwin, but it doesn't actually work yet. ;) The code reorg might be of immediate interest, though. -gregg _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
