[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] cygwin build
Re: [Tinycc-devel] cygwin build
Thu, 30 Aug 2007 15:14:25 -0500
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
*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"
> > > 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:
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:
Jonathan Corbet's article about same:
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:
> 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.
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.