Re: [Tinycc-devel] cygwin build

[Gregg Reynolds]

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