Date: Thu, 18 Nov 1999 13:24:02 +0100 From: Marcel Moolenaar <marcel@scc.nl> To: John Birrell <jb@cimlogic.com.au> Cc: arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <3833EFE2.A6D975F2@scc.nl> References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell wrote: > > On Thu, Nov 18, 1999 at 10:16:59AM +0100, Marcel Moolenaar wrote: > > Cross-compilation and cross-building don't share the same problem-space > > and each have a different set of goals (non necessarily disjunct). > > I think that cross-compilation is a superset of cross-building if you > want to make a distinction between the too. No. Cross-building has to deal with issues that aren't in the problem domain of cross-compilation. A cross-build has to be able to build itself (by this I mean that the build process has to handle incompatibilities and has to generate its own tools). This is not an issue in cross-compilation, where the problem domain is limited to how a user should make and install cross-compilation tools. > > My personal thoughts on the subject of the ability to make > > cross-compilers from within our source tree are *at this time* dominated > > by it's use for cross-building. I don't see a point to bloat our source > > tree with the ability to make a cross-compilation toolset for NT (for > > example) while there's this really neat ports collection in which we can > > add anything that's not directly related/necessary for out base-system. > > The build I have avoids bloat for those who don't want the cross-compilation > tools. I want the build system to be flexible enough to get tools "for > all seasons". To me, the build makefiles are the key to it. I rarely > get what I want out of Cygnus' configure shit^H^H^Htuff. I don't understand you. You duplicate the entire /usr/src/gnu/usr.bin/cc tree for each architecture you want to be able to build a cross-compiler for and still claim you *avoid* bloat? The build system should first and for all be able to build a FreeBSD system. It should be flexible enough to maintain it, to secure backward compatibility of it and to adapt it the future. By your logic you would include every possible mailer, editor, scripting tool, daemon and what not in the source tree "just to be flexible for all seasons". I think it's clear that we have in our source tree only those tools (and configuration of those tools) that make up a basic FreeBSD system. Additional cross-compilation tools are best be added to the ports collection (IMO of course). > I can easily cross-build FreeBSD sources targeted to NetBSD/m68k/aout > the way I build the compiler. And I can cross-build non-FreeBSD sources > targeted at LynxOS/PowerPC or NT/i386. The binutils makefiles in the > tree already support that. Extending them to other architectures is > trivial. I want the compiler build to be the same way. There is very > little bloat (just a few more makefiles) for those who only want to > build. Your argument applies just as well for the ports collection, with the addition that the ports collection is way more flexible than the source tree! > I want to see FreeBSD become a serious contender as a development > platform (preferably out of the box). It already is. Adding cross-compilation tools in the source tree *prevents* cross-compilation tools to be added at installation time. You always have to install the sources and make your own cross-compiler before you can use it. That's not out of the box! Out of the box is saying at installation time (FreeBSD's that is) that you want compiler this-for-that, gas foo-for-bar and so on and so forth. The installer installs the packages (!!!!) and you're up and running. That's out of the box!!!! Hell, you can even add the includes and libraries for a specific platform to the ports collection and have it installed at the same time. That way you have a fully *useful* cross-compilation toolset that allows you to make NT binaries immediately after installation of FreeBSD. What more do you want? > > My suggestion is this: > > Let's talk cross-building first and fix our make world. When release 4.0 > > is out we have the time and the (inner) peace to discuss how we think we > > should help developers that eat cross-compilers for breakfast :-) > > I think we can do both at the same time. I don't think that's wise. We clearly have conflicting opinions on the matter of how and where to provide cross-compilation toolsets. I want to postpone that discussion until after we have secured our upgrade path. > We seem to disagree on the mechanics of how we should drive a cross-build. > _I_ think we should use MACHINE and MACHINE_ARCH which are set in make(1) > as a convenience for host builds, but can be overridden for cross-builds. I do to (now). I first introduced TARGET_ARCH for fundamental reasons. After implementing it, I found out that I was only changing A for B without solving a problem. I therefore abandoned the use of TARGET_ARCH as a replacement for MACHINE_ARCH in all makefiles. I want to reintroduce TARGET_ARCH with an entirely different function and meaning: What output should our compiler toolset generate. > They are not there for any other make function AFAIK. I agree that the > make(1) man page doesn't support this, but I think that is just a few > paragraphs of documentation that can be "fixed" (or changed to suit the > new world order). The manpage does not describe how the source actually works, therefore it should be updated. You can override MACHINE and MACHINE_ARCH; make allows that. Therefore, I agree. > What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH > or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. > I think we can just do what Cygnus does and build a dedicated version > of gcc for each target. Instead of duplicating subtrees I will use a single variable to handle that. That variable is going to be TARGET_ARCH. We are telling our compiler toolset what it should generate. Whether that is to be considered cross-compilation, depends on the system the compiler is going to run on eventually. The former will be denoted by TARGET_ARCH, the latter by MACHINE_ARCH. We're building a cross-compiler is TARGET_ARCH != MACHINE_ARCH. This is all it needs. Clean, simple and very intuitive. > I also don't want to see make(1) customized. I would like to ask that > we use the version of make from 2.2.5 (or whenever the -m switch was > first implemented) as the reference. If we can't do a cross-build with > an old version of make like that, then we're doing something wrong. Who said anything about customizing make(1). I get the impression you just don't (want to) know what I'm actually trying say? Do you actually understand me? > At work I have to live with GNU make because of portability issues > across Solaris, NT, Linux and FreeBSD. I'm tempted to suggest that we > drop BSD make in favour of gmake. I bet a suggestion like that will > wake people up. 8-) I'm only half joking. John, I think I understand your situation, at least I hope I do. Your personal situation is just what it is: your personal situation. I must admit, it really sound like a sub-optimal, hard-to-deal-with, bloody-irritating and not-so-pleasant-at-all kind of situation. But (you felt it coming :-), I don't think your situation is important enough to others and FreeBSD at large that we should adopt FreeBSD to it. The best thing we can do (IMO) is make your life easier by making ports of all those tools so that you (and others) can install (and deinstall) them with more ease than ever possible than if they were in the source tree. What I'm saying is this: Don't let your personal situation (frustration?) influence your good judgement. FOOTNOTE: This is all IMO or, IMHO given the last paragraph. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3833EFE2.A6D975F2>