[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] cygwin build
From: |
Gregg Reynolds |
Subject: |
Re: [Tinycc-devel] cygwin build |
Date: |
Thu, 30 Aug 2007 00:17:54 -0500 |
On 8/29/07, Rob Landley <address@hidden> 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