Re: [Tinycc-devel] cygwin build

[Rob Landley]

On Thursday 30 August 2007 12:17:54 am Gregg Reynolds wrote:
> 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.

I'm all for it, but could I get it as a separate patch please.

> > >   * 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.

*shrug*  Again, not against it, just please send it as a separate patch so I 
can evaluate it on its own merits...

> > >   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.

Just a random comment, not really an objection...

> > > 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.

Ok, what we need is a way to tell configure where each of the four paths live, 
explicitly and individually:

  Look for the system header files _here_.
  Look for/install the compiler header files _here_.
  Look for the system libraries _here_.
  Look for/install the compiler libraries _here_.

I'm unaware of tcc calling out to external utilities, and if it does so it 
should use $PATH like the rest of the world does (pointed look at gcc for 
being evil and stupid).  And where the source code you're compiling is 
something even gcc doesn't get all that confused about...

Changing the defaults is not an improvement if we don't gain the ability to 
override them during ./configure.

Doing --bindir and --libdir isn't an improvement here.  There are _two_ 
library paths, and if you don't want the binaries to go in /usr then you're 
probably going to set --prefix to something else.  (Not suggesting removing 
them, I'm just pointing out that the traditional gnu assumptions provide 
non-orthogonal knobs that don't control the important stuff.)

> 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.

A) With tcc, this is not the case.
B) Have you ever seen a compiler actually do this?
C) If there _is_ a header to examine, why hide it?

> > (When did user-visible become a bad thing?)
>
> When users became annoying?

If you don't trust your users, why are you doing open source programming?

> 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 didn't say I was going to humor support requests from somebody who did 
something stupid, but I'm not going to treat them like immature idiots before 
I even know who they are.  (That's what C++ is for, with all those "private" 
declarations.)

> > >  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 /.
> ;)

This is not my problem. :)

> gcc -H worked, once I knew -H was there. 

gcc has a "-print-libgcc-file-name" too.  And the way the LInux kernel finds 
the compiler include directory is "-print-file-name=include" which, if you 
understand what is actually going on, is exploiting a _bug_ but is now 
required behavior and, apparently there isn't really an obvious better way to 
do that, so we'll have to special-case support that if we want to build the 
Linux kernel.  (I know this because I had to add special case support for 
this in my wrapper script, to make the linux kernel compile.)

The standard I look at first is SUSv3, which says:
http://www.opengroup.org/onlinepubs/009695399/utilities/c99.html

I try not to implement any gcc cruft that no packages are actually _using_ 
yet.  Bug reports document what actually needs this, and until then 
infrastructure in search of a user is unnecessary bloat.

> > > 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.

hg -clone http://landley.net/hg/tinycc tinycc-cygwin

Whee, you're done.  Tell me when there's something for me to pull, or send me 
patches, or use "hg export" and I can use "hg import"...

> Everything nice and segregated until you 
> decide it's worth merging into the master.

Yes, see above.  I don't even need to have a copy of this cygwin tree, you 
just send me changes generated from it.  You can put it up on your own 
webpage if you like.  This is the point of distributed source control, which 
is designed to merges changes from different trees with a common history.

> 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.

Linus Torvalds explained it, at some length, at the KDE developers recently:

Linus's message:
  http://lwn.net/Articles/246381/

Jonathan Corbet's article about same:
  http://lwn.net/Articles/246313/

Linus was talking about git rather than hg, but git is just "the same kind of 
thing implemented in 1/10th as much code because they did it in python".

> > 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.

Any branch can pull from any other branch, or you can send bundled "groups of 
patches, in order, with associated metadata like author info and file 
renames" which is what that import/export thing does.  You can generate one 
of those from your tree, and I can apply it to my tree.  You can pull -u from 
my tree into your tree and it should merge stuff up (I don't know what it'll 
do about conflicts because I haven't actually hit one it can't auto-merge 
yet, but I suspect it'll stop and prompt you.)

Bitkeeper used to have a three-way-merge gui:
http://kernel.org/doc/ols/2002/ols2002_proceedings-pages-197-212.pdf

> 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.

I'd like to apply them separately.  If you could send me the reorg code in 
discrete chunks so I can evaluate and apply 'em one at a time, why don't we 
get that out of the way while you get cygwin working.

> -gregg

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.