Date: Tue, 02 Jul 2002 17:00:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jan Lentfer <Jan.Lentfer@web.de> Cc: Jan Lentfer <jan@localhost.homeip.net>, Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-alpha <freebsd-alpha@freebsd.org> Subject: Re: List of ports that can be compiled with compaq-cc Message-ID: <3D223E91.A71CC743@mindspring.com> References: <3D21F1C8.2010708@web.de> <15650.6127.427432.57976@grasshopper.cs.duke.edu> <3D22188C.2000603@web.de> <3D222E25.62D5E4D0@mindspring.com> <3D222EF3.8070700@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Jan Lentfer wrote: > >>But seriously.... How should we manage this? I'd say a website (with > >>regestration for submitters???) where we could hold the status of all ports > > > >Modify the ports.mk so that it will check a flag, and, if it is > >present and the compiler is present, have it "prefer" the Compaq > >compiler. Then for those ports where it works, just set the flag > >in their Makefile. > > > >Allow this behaviour to be globally overridden via make.conf. > > But before we could do this we would need a list of "known-to-work" ports. No, you wouldn't. That's why I designed it that way: so you could incrementally add to the list of "known-to-work" ports over time, incrementally, starting at 0 or 1 ports. It also allows for "Yes, but..."; for example, if some port did work with the Compaq compiler, but the code result was somehow inferior to the non-Compaq compiler, you could add the flags that it worked, then comment them out, with a text comment saying why. It also allows for the Compaq compiler to become a port dependency for the ports best compiled with the Compaq compiler, at a later date. You appear to want a lot of people to install the Compaq tools on a minority platform, and spend a lot of effort verifying ports on your behalf, just so they can tag this fact in a comment in the "README" or Makefile for a port, and obtain no benefit from the effort, other than the tiny number of people who read these files before executing "make" on them, in order to build a given port. With respect, the single most important thing that makes effort happen with regard to Open Source is working code. I've proven this over and over again. FreeBSD is around because 386BSD code *worked*, thanks to my efforts with the patchkit. OpenLDAP is around because of the patches that I both collected into a single whole, and made on my own, as an experiment to prove this thesis; on its own, the University of Michigan LDAP code needed to *work* before it gained wide acceptance. Eric Raymond can take his "The Cathedral and the Bazaar" voo-doo and stuff them. I have mathematical models. I can *prove* my thesis over 9 Open Source Software projects in which I have participated directly, and over another half a dozen which I've analyzed. If you want something that's going to result in ports available for you, which can be compiled out-of-the-box with the Compaq compiler, the only approach that's going to work consistantly is going to be the approach I've described. The approach that you described will not result in what you say you want to have happen. The emergent properties of your approach is a significant division of effort. If you don't care about what happens, and you just want a project, then, by all means, declare one at Sourceforge, and have it get nowhere, just like all other non-working projects proceed to failure after declaration without working code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D223E91.A71CC743>