Re: cvs commit: src Makefile.inc1
On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote: scottl 2003/08/31 23:43:25 PDT FreeBSD src repository Modified files: .Makefile.inc1 Log: Clarify the numbering of some of the build stages. Revision ChangesPath 1.389 +9 -9 src/Makefile.inc1 How about if we get rid of the numbering here completely? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: cvs commit: src Makefile.inc1
Ruslan Ermilov wrote: On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote: scottl 2003/08/31 23:43:25 PDT FreeBSD src repository Modified files: .Makefile.inc1 Log: Clarify the numbering of some of the build stages. Revision ChangesPath 1.389 +9 -9 src/Makefile.inc1 How about if we get rid of the numbering here completely? Cheers, I like the numbering since it can give me an idea of progress at a quick glance without having to memorize the name of each step. But, I'm flexible, I guess. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src Makefile.inc1
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : Clarify the numbering of some of the build stages. : How about if we get rid of the numbering here completely? : I like the numbering since it can give me an idea of progress at a : quick glance without having to memorize the name of each step. But, : I'm flexible, I guess. I'm flxible too, but I kinda like the numbering, so long as I know what is being counted to :-) (eg, 1.1, 1.2, 1.3, 2.1, 2.2 ... 4.6 vs 1, 2, 3, ... 26 doesn't matter, so long as I know the terminus). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
4.0-RELEASE - 4.5-STABLE now possible (was: Re: cvs commit: src Makefile.inc1 src/gnu/usr.bin/perl Makefile Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/library Makefile.inc src/gnu/usr.bin/perl/miniperl Makefile src/gnu/usr.bin/perl/pod Makefile.inc ...)
[Sorry for a cross-post, it's intentional.] The patch below brings us the following functionality: 1. FreeBSD 4.0 can be source upgraded to FreeBSD 4.5-STABLE. (Only standard make world has been tested, with an empty /etc/make.conf.) FreeBSD 4.0 could be source upgraded to FreeBSD 5.0 even before this patch. :-) 2. FreeBSD 4.x can cross-build RELENG_4 world for a different arch. One needs to set TARGET_ARCH/TARGET accordingly. The changes were passed through the following tests: make world kernel (on a 4.0-RELEASE machine) make world kernel TARGET_ARCH=alpha (on a 4.5-STABLE machine) make release -DNODOC -DNOPORTS (on a 4.5-STABLE machine) The patch also MFC'es Makefile.inc1,v 1.180 (sys/boot/pc98/boot2 has been converted to an ELF binary). On Tue, Feb 19, 2002 at 08:21:35AM -0800, Ruslan Ermilov wrote: ru 2002/02/19 08:21:35 PST Modified files:(Branch: RELENG_4) .Makefile.inc1 gnu/usr.bin/perl Makefile Makefile.inc gnu/usr.bin/perl/libperl Makefile gnu/usr.bin/perl/library Makefile.inc gnu/usr.bin/perl/miniperl Makefile gnu/usr.bin/perl/pod Makefile.inc gnu/usr.bin/perl/x2p Makefile.inc share/mk bsd.lib.mk Log: MFC: cross-building fixes. RevisionChangesPath 1.141.2.40 +46 -74src/Makefile.inc1 1.9.2.2 +1 -5 src/gnu/usr.bin/perl/Makefile 1.12.2.4+6 -1 src/gnu/usr.bin/perl/Makefile.inc 1.9.2.3 +1 -4 src/gnu/usr.bin/perl/libperl/Makefile 1.5.2.3 +1 -2 src/gnu/usr.bin/perl/library/Makefile.inc 1.11.2.2+25 -20src/gnu/usr.bin/perl/miniperl/Makefile 1.2.2.2 +1 -2 src/gnu/usr.bin/perl/pod/Makefile.inc 1.5.2.2 +1 -2 src/gnu/usr.bin/perl/x2p/Makefile.inc 1.91.2.5+2 -2 src/share/mk/bsd.lib.mk -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Thu, Oct 25, 2001 at 11:37:28AM -0400, Andrew Gallatin wrote:
x86 sysinstall seems to have a hardcoded reference to /boot. Eg:
=== usr.sbin/spray
rm -f .depend
mkdep -f .depend -a -nostdinc
-I/usr/obj/i386/home/gallatin/current/src/alpha/usr/include
/home/gallatin/current/src/usr.sbin/spray/spray.c
cd /home/gallatin/current/src/usr.sbin/spray; make _EXTRADEPEND
echo spray: /usr/obj/i386/home/gallatin/current/src/alpha/usr/lib/libc.a
/usr/obj/i386/home/gallatin/current/src/alpha/usr/lib/librpcsvc.a .depend
=== usr.sbin/sysinstall
rm -f makedevs.tmp
echo '#include sys/types.h' makedevs.tmp
./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' makedevs.tmp
./rtermcap cons25w | file2c 'const char termcap_cons25w[] = {' ',0};'
makedevs.tmp
./rtermcap cons25 | file2c 'const char termcap_cons25[] = {' ',0};' makedevs.tmp
./rtermcap cons25-m | file2c 'const char termcap_cons25_m[] = {' ',0};'
makedevs.tmp
./rtermcap cons25r | file2c 'const char termcap_cons25r[] = {' ',0};'
makedevs.tmp
./rtermcap cons25r-m | file2c 'const char termcap_cons25r_m[] = {' ',0};'
makedevs.tmp
./rtermcap cons25l1 | file2c 'const char termcap_cons25l1[] = {' ',0};'
makedevs.tmp
./rtermcap cons25l1-m | file2c 'const char termcap_cons25l1_m[] = {' ',0};'
makedevs.tmp
./rtermcap vt100 | file2c 'const char termcap_vt100[] = {' ',0};' makedevs.tmp
./rtermcap xterm | file2c 'const char termcap_xterm[] = {' ',0};' makedevs.tmp
file2c 'u_char boot0[] = {' '};' /boot/boot0 makedevs.tmp
cannot open /boot/boot0: no such file
*** Error code 2
Stop in /home/gallatin/current/src/usr.sbin/sysinstall.
*** Error code 1
Stop in /home/gallatin/current/src/usr.sbin.
*** Error code 1
Stop in /home/gallatin/current/src.
*** Error code 1
Stop in /home/gallatin/current/src.
*** Error code 1
Stop in /home/gallatin/current/src.
That's the bug in Makefile. We can abuse the fact that sys/ is listed
first in Makefile.inc1, and use the version from ${.OBJDIR} if it
exists. Could you please try this patch:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/Makefile,v
retrieving revision 1.117
diff -u -r1.117 Makefile
--- Makefile2001/09/05 07:12:19 1.117
+++ Makefile2001/10/25 16:59:05
@@ -21,6 +21,27 @@
CLEANFILES=makedevs.c rtermcap rtermcap.tmp dumpnlist
CLEANFILES+= keymap.tmp keymap.h
+.if ${MACHINE_ARCH} == i386
+.if exists(${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0)
+BOOT0= ${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0
+.else
+BOOT0= /boot/boot0
+.endif
+.if ${MACHINE} == i386
+.if exists(${.OBJDIR}/../../sys/boot/i386/mbr/mbr)
+MBR= ${.OBJDIR}/../../sys/boot/i386/mbr/mbr
+.else
+MBR= /boot/mbr
+.endif
+.elif ${MACHINE} == pc98
+.if exists(${.OBJDIR}/../../sys/boot/pc98/boot0.5/boot0.5)
+BOOT05=${.OBJDIR}/../../sys/boot/pc98/boot0.5/boot0.5
+.else
+BOOT05=/boot/boot0.5
+.endif
+.endif
+.endif
+
makedevs.c:Makefile rtermcap
rm -f makedevs.tmp
echo '#include sys/types.h' makedevs.tmp
@@ -54,17 +75,16 @@
./rtermcap xterm | \
file2c 'const char termcap_xterm[] = {' ',0};' \
makedevs.tmp
-.if ${MACHINE} == i386
- file2c 'u_char boot0[] = {' '};' /boot/boot0 makedevs.tmp
+.if ${MACHINE_ARCH} == i386
+ file2c 'u_char boot0[] = {' '};' ${BOOT0} makedevs.tmp
echo size_t boot0_size = sizeof(boot0); makedevs.tmp
- file2c 'u_char mbr[] = {' '};' /boot/mbr makedevs.tmp
+.if ${MACHINE} == i386
+ file2c 'u_char mbr[] = {' '};' ${MBR} makedevs.tmp
echo size_t mbr_size = sizeof(mbr); makedevs.tmp
-.endif
-.if ${MACHINE} == pc98
- file2c 'u_char boot0[] = {' '};' /boot/boot0 makedevs.tmp
- echo size_t boot0_size = sizeof(boot0); makedevs.tmp
- file2c 'u_char boot05[] = {' '};' /boot/boot0.5 makedevs.tmp
+.elif ${MACHINE} == pc98
+ file2c 'u_char boot05[] = {' '};' ${BOOT05} makedevs.tmp
echo size_t boot05_size = sizeof(boot05); makedevs.tmp
+.endif
.endif
mv makedevs.tmp makedevs.c
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Ruslan Ermilov writes:
+.if ${MACHINE_ARCH} == i386
+.if exists(${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0)
+BOOT0= ${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0
+.else
+BOOT0= /boot/boot0
+.endif
But its failing at the depends stage. At this stage, boot0 will not
have been built yet:
elf make world started on Thu Oct 25 13:26:14 EDT 2001
Rebuilding the temporary build tree
stage 1: bootstrap tools
stage 2: cleaning up the object tree
stage 2: rebuilding the object tree
stage 2: build tools
stage 3: cross tools
stage 4: populating /usr/obj/i386/home/gallatin/current/src/alpha/usr/include
stage 4: building libraries
stage 4: make dependencies
kaboom!
To confirm, I tried it with your patch it still failed.
You should be able to duplicate this on your x86 by just mv'ing
/boot/boot0 out of the way while you try a buildworld.
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On 25-Oct-01 Andrew Gallatin wrote:
Ruslan Ermilov writes:
+.if ${MACHINE_ARCH} == i386
+.if exists(${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0)
+BOOT0=${.OBJDIR}/../../sys/boot/${MACHINE}/boot0/boot0
+.else
+BOOT0=/boot/boot0
+.endif
But its failing at the depends stage. At this stage, boot0 will not
have been built yet:
elf make world started on Thu Oct 25 13:26:14 EDT 2001
Rebuilding the temporary build tree
stage 1: bootstrap tools
stage 2: cleaning up the object tree
stage 2: rebuilding the object tree
stage 2: build tools
stage 3: cross tools
stage 4: populating
/usr/obj/i386/home/gallatin/current/src/alpha/usr/include
stage 4: building libraries
stage 4: make dependencies
kaboom!
To confirm, I tried it with your patch it still failed.
You should be able to duplicate this on your x86 by just mv'ing
/boot/boot0 out of the way while you try a buildworld.
Yeah, this is a bit of a tricky problem. Probably what should really happen,
is that sysinstall should read these files from /boot on the existing
filesystem, and then we just guarantee that they are present in the MFS root in
the boot floppies. That is probably the best solution to the problem.
Drew
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
After unhooking sysinstall from the build, we have almost total success. The only remaining problem is that the kernel install failed, due to a missing hints file in my DESTIR's /boot. One interesting bit of trivia -- an alpha crossbuilds an x86 world roughly 30-40% faster than it builds a native world. The alpha gcc backend is a pig. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On 21 May 2001, Cyrille Lefevre wrote: Bruce Evans [EMAIL PROTECTED] writes: Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. some times ago, I've ported linux fdisk to native freebsd. if you really need it, I could make it a port ? I don't need it myself (I only ran it to see if it supported Linux extended partitions (it didn't, at least in it's list of known partition types)). This is for the old Linux fdisk with a dumb terminal interface which hadn't changed much (in 1997) since it was first implemented in 1991 or 1992. It doesn't have a good interface, but I rather like it since most of it was apparently copied from the one I implemented in Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical interface. Which version did you port? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Bruce Evans wrote: On 21 May 2001, Cyrille Lefevre wrote: [snip] I don't need it myself (I only ran it to see if it supported Linux extended partitions (it didn't, at least in it's list of known partition types)). This is for the old Linux fdisk with a dumb terminal interface which hadn't changed much (in 1997) since it was first implemented in 1991 or 1992. It doesn't have a good interface, but I rather like it since most of it was apparently copied from the one I implemented in Minix fdisk in 1988 or 1989 :-). Others might prefer a more graphical interface. Which version did you port? the ones from util-linux-2.10s.tar.gz (or .src.rpm?) cfdisk and fdisk seems to work good. for instance, sfdisk make a core! I did need it in the past, but in fact, I've done what I want w/ the bsd one. it was when I upgrade MaxBlast which is a software BIOS to see large drives. it changed the IDs of all (DOS?) primary and partitions to 0x55 and FreeBSD didn't like it at all. the problem is that ID didn't make a difference between primary (0xC) and extended (0xF) partitions... CC shortened. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Bruce Evans [EMAIL PROTECTED] writes: Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. some times ago, I've ported linux fdisk to native freebsd. if you really need it, I could make it a port ? Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Bruce Evans [EMAIL PROTECTED] writes: Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. some times ago, I've ported linux fdisk to native freebsd. if you really need it, I could make it a port ? Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Ta. On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote:
[...]
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
I have removed the -I${.CURDIR}/.../sys from the half of Makefiles
that do not actually need it. Here is the rest of Makefiles that
have the -I${.CURDIR}/.../sys in them, and it's currently required
because they use headers from /sys that do not get installed into
/usr/include (but should):
sbin/atm/atm/Makefile
sbin/atm/fore_dnld/Makefile
sbin/atm/ilmid/Makefile
sbin/mount_null/Makefile
sbin/mount_portal/Makefile
sbin/mount_umap/Makefile
sbin/mount_union/Makefile
sbin/vinum/Makefile
usr.sbin/acpi/Makefile.inc very interesting example!
usr.sbin/ancontrol/Makefile
usr.sbin/dpt/dpt_ctlinfo/Makefile
usr.sbin/dpt/dpt_ctls/Makefile
usr.sbin/dpt/dpt_dm/Makefile
usr.sbin/dpt/dpt_led/Makefile these even don't compile!!!
usr.sbin/dpt/dpt_sig/Makefile
usr.sbin/dpt/dpt_softc/Makefile
usr.sbin/dpt/dpt_sysinfo/Makefile
usr.sbin/mlxcontrol/Makefile
usr.sbin/pciconf/Makefile
usr.sbin/pnpinfo/Makefile
usr.sbin/pstat/Makefile
usr.sbin/raycontrol/Makefile
usr.sbin/setkey/Makefile
usr.sbin/sicontrol/Makefile
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Fri, May 18, 2001 at 05:11:11PM +0300, Ruslan Ermilov wrote:
On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote:
[...]
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
I have removed the -I${.CURDIR}/.../sys from the half of Makefiles
that do not actually need it. Here is the rest of Makefiles that
have the -I${.CURDIR}/.../sys in them, and it's currently required
because they use headers from /sys that do not get installed into
/usr/include (but should):
[...]
sbin/mount_null/Makefile
sbin/mount_portal/Makefile
sbin/mount_umap/Makefile
sbin/mount_union/Makefile
FS headers should go into /usr/include/fs/fsfs.h, one per
each filesystem.
Boris, could you please move smbfs.h one directory up from the
/usr/include/fs/smbfs/? Also, installing of smbfs_node.h and
smbfs_subr.h seems to be not required as these are used solely
within the kernel.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
Brian Somers wrote: John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Done. Ta. On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev tree with an average of 1+epsilon files per directory is even worse than a /sys/dev tree with an average of about 3 files per directory (not counting 4 CVS files per directory). ppbus actually installs a lot of kernel-only headers so /sys/dev/ppbus is not all that small. Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev tree with an average of 1+epsilon files per directory is even worse than a /sys/dev tree with an average of about 3 files per directory (not counting 4 CVS files per directory). ppbus actually installs a lot of kernel-only headers so /sys/dev/ppbus is not all that small. Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Well, now we know what it shouldn't be :*0 I've created /usr/include/dev/digi/digiio.h pending any better suggestions. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Thu, May 17, 2001 at 08:14:10PM +1000, Bruce Evans wrote: On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev tree with an average of 1+epsilon files per directory is even worse than a /sys/dev tree with an average of about 3 files per directory (not counting 4 CVS files per directory). ppbus actually installs a lot of kernel-only headers so /sys/dev/ppbus is not all that small. Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Might I guess it should probably be called /usr/include/sys/io[ctl], and digiio.h put there. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Where to put include files (was: cvs commit: src Makefile.inc1)
Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Might I guess it should probably be called /usr/include/sys/io[ctl], and digiio.h put there. Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd spell digiio.h /usr/include/sys/digi_io.h. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. We're not solaris :-). BSD traditionally spells things fooio.h for driver foo. FreeBSD changed the traditional place for devices, so one could argue for both /usr/include/sys/dev/foo/fooio.h or for /usr/include/sys/fooio.h. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
[cc'd to -arch and not to cvs-committers] For anyone that's reading -arch and hasn't seen this on -current, the thread is discussing userland sources that have -I../../sys in their Makefile and then #include sys/dev/blahio.h. I think everyone agrees that these headers should be made public, the question is ``where to put them ?''. Warner wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). The SHARED variable in src/include/Makefile makes this side of things tricky too - we've got to be careful that we either keep our sources together and maintain a resemblance of the hierarchy in /usr/include or split our sources. When I was working on Solaris I found it better to have the *io.h files in sys (separate from the driver) as it made it very clear that it was a public interface - the driver lived somewhere that just got built into a module and wasn't seen by the outside world. So I think I'd tend to vote (FWIW) for moving digiio.h (and other similar things) out of sys/dev/drivername/ and into sys/sys/. Comments ? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, May 17, 2001 at 05:37:54PM +0100, Brian Somers wrote:
[cc'd to -arch and not to cvs-committers]
For anyone that's reading -arch and hasn't seen this on -current, the
thread is discussing userland sources that have -I../../sys in their
Makefile and then #include sys/dev/blahio.h.
I think everyone agrees that these headers should be made public, the
question is ``where to put them ?''.
Warner wrote:
In message [EMAIL PROTECTED] Brian
Somers writes:
: Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd
: spell digiio.h /usr/include/sys/digi_io.h.
Actually, the more I think about it, the more I like putting it in
/usr/include/sys/fooio.h. We have lots of other files there now. The
down side to this approach is that it breaks up the driver sources
that we've been trying to concentrate into sys/dev/foo/* (or
introduces asymetry such that you can't just toss in a -I/sys and have
the same tree that gets stuck under /usr/include).
The SHARED variable in src/include/Makefile makes this side of things
tricky too - we've got to be careful that we either keep our sources
together and maintain a resemblance of the hierarchy in /usr/include
or split our sources.
When I was working on Solaris I found it better to have the *io.h
files in sys (separate from the driver) as it made it very clear that
it was a public interface - the driver lived somewhere that just got
built into a module and wasn't seen by the outside world.
So I think I'd tend to vote (FWIW) for moving digiio.h (and other
similar things) out of sys/dev/drivername/ and into sys/sys/.
Comments ?
More to that.
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Szilveszter Adam writes: : I think that cross-platform means compilation between i386 and alpha (and : possibly others) not different OS's:-) (Although admittedly you can build : Debian CDs on FreeBSD with linux emulation way better than you can build : say a -STABLE release on a -CURRENT box... ) Cross platform means any system that isn't the one that's installed which is usually the case when you are building the world. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, May 15, 2001 at 05:02:25PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Maxim Sobolev writes:
: Perhaps we could rip off the code that dumps keymap file into a
: little utility on its own and use this utility to bootstrap
: sysinstall. I could look into this direction if there aren't better
: ideas.
I think your idea of just defining PASTE is the best way to go. I
came up with it independently after trying a number of different ideas
on how to get around this.
FWIW, my gross hack to usr.sbin/kbdcontrol also worked:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile2001/03/26 14:40:28 1.8
+++ Makefile2001/05/16 07:19:20
@@ -3,6 +3,7 @@
PROG= kbdcontrol
SRCS= kbdcontrol.c lex.l
CFLAGS+= -I${.CURDIR}
+CFLAGS+=-I${.CURDIR}/../../sys
MAN= kbdcontrol.1 kbdmap.5
MLINKS= kbdmap.5 keymap.5
DPADD= ${LIBL}
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Warner Losh wrote: In message [EMAIL PROTECTED] Maxim Sobolev writes: : There is at least one easy way - we can check if PASTE : is defined and define it to be NOP if it isn't. This would allow : to use kbdcontrol as a bootstrap tool on 4-STABLE. : : See attached patch. Heh. I came up with this independently. It works. I hope I didn't step on any toes by commiting it. ;) Great minds think alike, you know. 8-) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, 15 May 2001, Ruslan Ermilov wrote:
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
Even running kbdcontrol might break cross-platform builds. Consider
running it on a host platform of Linux. It might fail attempting to
do a keyboard ioctl in its initalization. However, kbdcontrol -L
might work because it doesn't actually do any keyboard control.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote:
On Tue, 15 May 2001, Ruslan Ermilov wrote:
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
Even running kbdcontrol might break cross-platform builds. Consider
running it on a host platform of Linux. It might fail attempting to
do a keyboard ioctl in its initalization. However, kbdcontrol -L
might work because it doesn't actually do any keyboard control.
I think that cross-platform means compilation between i386 and alpha (and
possibly others) not different OS's:-) (Although admittedly you can build
Debian CDs on FreeBSD with linux emulation way better than you can build
say a -STABLE release on a -CURRENT box... )
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Thu, May 17, 2001 at 12:51:59AM +1000, Bruce Evans wrote: On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. I would probably volunteer for doing this. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Szilveszter Adam wrote: On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote: Even running kbdcontrol might break cross-platform builds. Consider running it on a host platform of Linux. It might fail attempting to do a keyboard ioctl in its initalization. However, kbdcontrol -L might work because it doesn't actually do any keyboard control. I think that cross-platform means compilation between i386 and alpha (and possibly others) not different OS's:-) (Although admittedly you can build I have higher standards :-). Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. I have -I../../sys in src/usr.sbin/digictl/Makefile. I put it there because the digi ioctl interface header isn't actually installed anywhere. There's no good reason for this except that I couldn't think of a good place (/usr/include/sys/digi/ ?). I cribbed the idea from the vinum(8) build. How should this be done - and where should I install digiio.h if that's what's required ? Cheers. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote:
ru 2001/05/14 10:21:02 PDT
Modified files:
.Makefile.inc1
Log:
Add kbdcontrol(1) to bootstrap-tools.
This fixes the upgrade path breakage in usr.sbin/sysinstall.
Revision ChangesPath
1.201 +2 -1 src/Makefile.inc1
Argh, this doesn't work either. I first tried this with some stuff
commented out in Makefile.inc1, and it succeeded. But at the time
kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is
not yet populated, and kbdcontrol.c requires an up-to-date header
files. OTOH, the bootstrap-tools are supposed to be built under
the host environment, so compiling against CURRENT sources would
be a bug. Ideas?
--
stage 1: bootstrap tools
--
[...]
cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make
install
/usr/obj/CURRENT/usr/src/i386/CURRENT/usr/src/usr.sbin/kbdcontrol created for
/CURRENT/usr/src/usr.sbin/kbdcontrol
lex -t /CURRENT/usr/src/usr.sbin/kbdcontrol/lex.l lex.c
rm -f .depend
mkdep -f .depend -a-I/CURRENT/usr/src/usr.sbin/kbdcontrol
-I/usr/obj/CURRENT/usr/src/i386/usr/include
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c
cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND
echo kbdcontrol: /usr/obj/CURRENT/usr/src/i386/usr/lib/libc.a
/usr/obj/CURRENT/usr/src/i386/usr/lib/libl.a .depend
cc -O -pipe -I/CURRENT/usr/src/usr.sbin/kbdcontrol
-I/usr/obj/CURRENT/usr/src/i386/usr/include -c
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `get_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: `PASTE' undeclared (first use
in this function)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: (Each undeclared identifier is
reported only once
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: for each function it appears
in.)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:444: `PASTE' undeclared (first use
in this function)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `dump_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:646: `PASTE' undeclared (first use
in this function)
*** Error code 1
Stop in /CURRENT/usr/src/usr.sbin/kbdcontrol.
*** Error code 1
Stop in /CURRENT/usr/src.
*** Error code 1
Stop in /CURRENT/usr/src.
*** Error code 1
Stop in /CURRENT/usr/src.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
OK, more details on 4.3-STABLE - 5.0-CURRENT upgrade path breakage.
1. kbdcontrol(1) is used by usr.sbin/sysinstall/Makefile to generate
keymap.h with keyboard maps.
2. Recent usr.sbin/sysinstall/Makefile wants to generate keymap.h
from current keymap sources in ../../share/syscons/keymaps,
so it should use current kbdcontrol(1) as well because:
a) only -CURRENT kbdcontrol(1) understands ${KEYMAP_PATH}
b) only current kbdcontrol(1) may understand current keymap
file syntax, as is the keyboard paste feature for now.
3. So usr.sbin/kbdcontrol should be in Makefile.inc1:bootstrap-tools.
4. But bootstrap-tools are supposed to be built in a host environment,
and -CURRENT kbdcontrol(1) couldn't be built on -STABLE because it
requires -CURRENT sys/sys/kbio.h header (the PASTE define).
I'm currently testing with -I${.CURDIR}/../../sys added to the
kbdcontrol/Makefile, but this is a gross hack.
On Tue, May 15, 2001 at 04:19:57PM +0300, Ruslan Ermilov wrote:
On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote:
ru 2001/05/14 10:21:02 PDT
Modified files:
.Makefile.inc1
Log:
Add kbdcontrol(1) to bootstrap-tools.
This fixes the upgrade path breakage in usr.sbin/sysinstall.
Revision ChangesPath
1.201 +2 -1 src/Makefile.inc1
Argh, this doesn't work either. I first tried this with some stuff
commented out in Makefile.inc1, and it succeeded. But at the time
kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is
not yet populated, and kbdcontrol.c requires an up-to-date header
files. OTOH, the bootstrap-tools are supposed to be built under
the host environment, so compiling against CURRENT sources would
be a bug. Ideas?
--
stage 1: bootstrap tools
--
[...]
cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make
install
/usr/obj/CURRENT/usr/src/i386/CURRENT/usr/src/usr.sbin/kbdcontrol created for
/CURRENT/usr/src/usr.sbin/kbdcontrol
lex -t /CURRENT/usr/src/usr.sbin/kbdcontrol/lex.l lex.c
rm -f .depend
mkdep -f .depend -a-I/CURRENT/usr/src/usr.sbin/kbdcontrol
-I/usr/obj/CURRENT/usr/src/i386/usr/include
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c
cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND
echo kbdcontrol: /usr/obj/CURRENT/usr/src/i386/usr/lib/libc.a
/usr/obj/CURRENT/usr/src/i386/usr/lib/libl.a .depend
cc -O -pipe -I/CURRENT/usr/src/usr.sbin/kbdcontrol
-I/usr/obj/CURRENT/usr/src/i386/usr/include -c
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `get_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: `PASTE' undeclared (first use
in this function)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: (Each undeclared identifier
is reported only once
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: for each function it appears
in.)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:444: `PASTE' undeclared (first use
in this function)
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `dump_entry':
/CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:646: `PASTE' undeclared (first use
in this function)
*** Error code 1
Stop in /CURRENT/usr/src/usr.sbin/kbdcontrol.
*** Error code 1
Stop in /CURRENT/usr/src.
*** Error code 1
Stop in /CURRENT/usr/src.
*** Error code 1
Stop in /CURRENT/usr/src.
Cheers,
--
Ruslan ErmilovOracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED]FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.orgThe Power To Serve
http://www.oracle.com Enabling The Information Age
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, May 15, 2001 at 05:33:54PM +0300, Ruslan Ermilov wrote:
OK, more details on 4.3-STABLE - 5.0-CURRENT upgrade path breakage.
1. kbdcontrol(1) is used by usr.sbin/sysinstall/Makefile to generate
keymap.h with keyboard maps.
2. Recent usr.sbin/sysinstall/Makefile wants to generate keymap.h
from current keymap sources in ../../share/syscons/keymaps,
so it should use current kbdcontrol(1) as well because:
a) only -CURRENT kbdcontrol(1) understands ${KEYMAP_PATH}
b) only current kbdcontrol(1) may understand current keymap
file syntax, as is the keyboard paste feature for now.
3. So usr.sbin/kbdcontrol should be in Makefile.inc1:bootstrap-tools.
4. But bootstrap-tools are supposed to be built in a host environment,
and -CURRENT kbdcontrol(1) couldn't be built on -STABLE because it
requires -CURRENT sys/sys/kbio.h header (the PASTE define).
I'm currently testing with -I${.CURDIR}/../../sys added to the
kbdcontrol/Makefile, but this is a gross hack.
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
G'luck,
Peter
--
This sentence would be seven words long if it were six words shorter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Ruslan Ermilov writes: : Doing it this way would break cross-platform builds. I'm not seeing this breakage, but I have some simple hacks in my tree. Lemme see if I'm just lucky, or if those hacks actually work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
Ruslan Ermilov wrote:
On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote:
ru 2001/05/14 10:21:02 PDT
Modified files:
.Makefile.inc1
Log:
Add kbdcontrol(1) to bootstrap-tools.
This fixes the upgrade path breakage in usr.sbin/sysinstall.
Revision ChangesPath
1.201 +2 -1 src/Makefile.inc1
Argh, this doesn't work either. I first tried this with some stuff
commented out in Makefile.inc1, and it succeeded. But at the time
kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is
not yet populated, and kbdcontrol.c requires an up-to-date header
files. OTOH, the bootstrap-tools are supposed to be built under
the host environment, so compiling against CURRENT sources would
be a bug. Ideas?
Perhaps we could rip off the code that dumps keymap file into a little utility on its
own and use this utility to bootstrap sysinstall. I could look into this
direction if there aren't better ideas.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Tue, 15 May 2001 21:57:44 +0300, Maxim Sobolev wrote:
Ruslan Ermilov wrote:
On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote:
ru 2001/05/14 10:21:02 PDT
Modified files:
.Makefile.inc1
Log:
Add kbdcontrol(1) to bootstrap-tools.
This fixes the upgrade path breakage in usr.sbin/sysinstall.
Revision ChangesPath
1.201 +2 -1 src/Makefile.inc1
Argh, this doesn't work either. I first tried this with some stuff
commented out in Makefile.inc1, and it succeeded. But at the time
kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is
not yet populated, and kbdcontrol.c requires an up-to-date header
files. OTOH, the bootstrap-tools are supposed to be built under
the host environment, so compiling against CURRENT sources would
be a bug. Ideas?
Perhaps we could rip off the code that dumps keymap
file into a little utility on its own and use this utility to
bootstrap sysinstall. I could look into this
direction if there aren't better ideas.
There is at least one easy way - we can check if PASTE
is defined and define it to be NOP if it isn't. This would allow
to use kbdcontrol as a bootstrap tool on 4-STABLE.
See attached patch.
-Maxim
Index: kbdcontrol.c
===
RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v
retrieving revision 1.35
diff -d -u -r1.35 kbdcontrol.c
--- kbdcontrol.c2001/05/14 06:15:07 1.35
+++ kbdcontrol.c2001/05/15 22:31:34
@@ -43,6 +43,10 @@
#include path.h
#include lex.h
+#ifndef PASTE
+#definePASTE NOP /* For compatibility with previous releases */
+#endif
+
char ctrl_names[32][4] = {
nul, soh, stx, etx, eot, enq, ack, bel,
bs , ht , nl , vt , ff , cr , so , si ,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Maxim Sobolev writes: : There is at least one easy way - we can check if PASTE : is defined and define it to be NOP if it isn't. This would allow : to use kbdcontrol as a bootstrap tool on 4-STABLE. : : See attached patch. Heh. I came up with this independently. It works. I hope I didn't step on any toes by commiting it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
In message [EMAIL PROTECTED] Maxim Sobolev writes: : Perhaps we could rip off the code that dumps keymap file into a : little utility on its own and use this utility to bootstrap : sysinstall. I could look into this direction if there aren't better : ideas. I think your idea of just defining PASTE is the best way to go. I came up with it independently after trying a number of different ideas on how to get around this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
