summaryrefslogtreecommitdiffstats
path: root/Makefile.inc1
Commit message (Collapse)AuthorAgeFilesLines
* Purely cosmetic but useful change.andreas1998-09-171-36/+36
| | | | | | | | | | | Make output of make world more readable for grep. Now a grep '>>>' world.log shows you the single stages through which the bootstrap process went as discussed on -current. Could be used to debug the bootstrap mechanism in case of trouble more easily. Would be fine if any further @echo "..." messages containing a description, what's going on, could use the new format: @echo ">>> ..."
* Two patches from the HARP people:phk1998-09-171-1/+2
| | | | | | | | Various Makefile related fixes. -Wformat fixes. Submitted by: Mike Spengler <mks@networkcs.com>
* libscsi is obsoleted by CAM.gibbs1998-09-171-2/+1
|
* (this is an extract from src/share/examples/atm/README)phk1998-09-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | =================================== HARP | Host ATM Research Platform =================================== HARP 3 What is this stuff? ------------------- The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center, Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed the Host ATM Research Platform (HARP) software, which allows IP hosts to communicate over ATM networks using standard protocols. It is intended to be a high-quality platform for IP/ATM research. HARP provides a way for IP hosts to connect to ATM networks. It supports standard methods of communication using IP over ATM. A host's standard IP software sends and receives datagrams via a HARP ATM interface. HARP provides functionality similar to (and typically replaces) vendor-provided ATM device driver software. HARP includes full source code, making it possible for researchers to experiment with different approaches to running IP over ATM. HARP is self-contained; it requires no other licenses or commercial software packages. HARP implements support for the IETF Classical IP model for using IP over ATM networks, including: o IETF ATMARP address resolution client o IETF ATMARP address resolution server o IETF SCSP/ATMARP server o UNI 3.1 and 3.0 signalling protocols o Fore Systems's SPANS signalling protocol What's supported ---------------- The following are supported by HARP 3: o ATM Host Interfaces - FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters - FORE Systems, Inc. PCA-200E ATM PCI Adapters - Efficient Networks, Inc. ENI-155p ATM PCI Adapters o ATM Signalling Protocols - The ATM Forum UNI 3.1 signalling protocol - The ATM Forum UNI 3.0 signalling protocol - The ATM Forum ILMI address registration - FORE Systems's proprietary SPANS signalling protocol - Permanent Virtual Channels (PVCs) o IETF "Classical IP and ARP over ATM" model - RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" - RFC 1577, "Classical IP and ARP over ATM" - RFC 1626, "Default IP MTU for use over ATM AAL5" - RFC 1755, "ATM Signaling Support for IP over ATM" - RFC 2225, "Classical IP and ARP over ATM" - RFC 2334, "Server Cache Synchronization Protocol (SCSP)" - Internet Draft draft-ietf-ion-scsp-atmarp-00.txt, "A Distributed ATMARP Service Using SCSP" o ATM Sockets interface - The file atm-sockets.txt contains further information What's not supported -------------------- The following major features of the above list are not currently supported: o UNI point-to-multipoint support o Driver support for Traffic Control/Quality of Service o SPANS multicast and MPP support o SPANS signalling using Efficient adapters This software was developed under the sponsorship of the Defense Advanced Research Projects Agency (DARPA). Reviewed (lightly) by: phk Submitted by: Network Computing Services, Inc.
* Hook up beforeinstall targets for libcam and libdevstatgibbs1998-09-151-1/+3
|
* I don't want to be the only one to use ``cut''. Use ``sed'' instead.obrien1998-09-101-2/+1
|
* Add ``usr/bin/cut'' to "build-tools" target.obrien1998-09-101-1/+2
| | | | Used in usr.sbin/amd/include/newvers.sh.
* Remove the NOPERL block to building Perl5.markm1998-09-091-4/+1
| | | | | Perl 5 will rebuild/bootstrap itself next time a make world is done with this in effect.
* Add the Perl5 bootstrap tools.markm1998-09-091-3/+4
|
* Another place to set NOPERL.markm1998-09-091-1/+4
|
* Remove tcl from /usr/src, according to prior agreement. BTW, tcl-8.0 *is*asami1998-09-051-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a port so there is nothing to be done on that side now. Approved by: jkh === To: "Jordan K. Hubbard" <jkh@time.cdrom.com> cc: Andreas Klemm <andreas@klemm.gtn.com>, current@freebsd.org Subject: Re: Make this a relese coordinator decision (was Re: ports-current/packages-current discontinued) From: David Greenman <dg@root.com> Date: Sun, 03 Aug 1997 20:23:31 -0700 >decision is, I'll respect it. Another chance to architect people's principles...I can hardly wait. Seems quite appropriate for a Sunday - I just need to get one of those collection plates (and money envelopes) so I can profit, too. :-) Tcl stays in /usr/src for now, but it needs to be kept up to date; same for perl. If Jordan doesn't have "setup" (written in tcl) ready for 3.0, then tcl will be yanked prior to the 3.0 release (and made into a port). As for the ports tree only supporting the last FreeBSD release, this seems sensible to me. The "ports" have always been a moving target between releases and the problem is only going to get worse when we expand to supporting other processor architectures. In any case, Satoshi is and always has been in charge of the ports tree and whatever he wants to do with it (within reason :-)) is his decision. Does this cover the issue completely? I admit to deleting messages in this thread with unusual fervor (people have FAR too much time on their hands!). There's a fair bit of reasoning behind the above, but since everyone is sick of arguing about this, I'll spare you the analysis. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
* Change i386 in a few paths to ${MACHINE} to support MACHINE=pc98.jb1998-09-051-4/+4
|
* Only run ldconfig if the OBJFORMAT is aout.jb1998-09-031-2/+2
|
* Force NOMAN and NOINFO on legacy-install as well as legacy build.jb1998-09-011-3/+3
|
* Add a target to check the consistency of the make OBJFORMAT variablejb1998-09-011-2/+25
| | | | | | | with the object format determined by objformat. This prevents foot shooting (a form of boot scooting for hackers?) where local changes to /etc/make.conf or /etc/make.conf.local try to override OBJFORMAT in an incomplete way.
* MACHINE -> MACHINE_ARCH to allow PC98 to define MACHINE=pc98.jb1998-08-311-10/+10
| | | | Submitted by: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.ac.jp>
* E-day build system changes.jb1998-08-311-0/+961
- Moved most of the guts of Makefile to Makefile.inc1 to become the backend for the build system. - The new Makefile doesn't suffer from problems including the wrong sys.mk because it doesn't use anything in there or bsd.own.mk. So, from now on, the proper build command is just `make world' (or buildworld). - The intermediate makefiles called Makefile.inc0 and Makefile.upgrade fiddle with the OBJFORMAT and MAKEOBJDIRPREFIX variables so that both aout and elf object trees can coexist. Makefile.upgrade contains the aout->elf transition build. - A cross build environment is now very close to reality. Specifying TOOLDIR, setting OBJFORMAT and MAKEOBJDIRPREFIX allow that. See the comments in Makefile for more info.
OpenPOWER on IntegriCloud