sanchayanmaity/minix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
minix/share/mk/bsd.prog.mk

655 lines
16 KiB
Makefile
Raw Normal View History

Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
# $NetBSD: bsd.prog.mk,v 1.278 2012/08/24 20:26:24 jmmv Exp $
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
# @(#)bsd.prog.mk 8.2 (Berkeley) 4/2/94
.ifndef HOSTPROG
Rename mkfiles from minix.*.mk to bsd.*.mk Makes things easier for pkgsrc
2010-06-25 20:29:09 +02:00
.include <bsd.init.mk>
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.include <bsd.shlib.mk>
.include <bsd.gcc.mk>
Cross compile on minix support * Remade patch so it works with minix patch tool. * New MINIX tar support -ox, so revert back to it In fetch scripts, tar had been replaced by bsdtar as the prebvious tar did not support the -o flag under minix, which is required to prevent usage of tar file stored user and group information. This introduces portability problems. As our new tar tool now support that flag revert back to improve portability.
2012-11-01 22:55:12 +01:00
.include <minix.gcov.mk>
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
#
# Definitions and targets shared among all programs built by a single
# Makefile.
#
##### Basic targets
realinstall: proginstall scriptsinstall
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.gdbinit:
rm -f .gdbinit
.if defined(DESTDIR) && !empty(DESTDIR)
echo "set solib-absolute-prefix ${DESTDIR}" > .gdbinit
.else
touch .gdbinit
.endif
.for __gdbinit in ${GDBINIT}
echo "source ${__gdbinit}" >> .gdbinit
.endfor
CLEANFILES+= a.out [Ee]rrs mklog core *.core .gdbinit
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(SHAREDSTRINGS)
CLEANFILES+=strings
.c.o:
${CC} -E ${CPPFLAGS} ${CFLAGS} ${.IMPSRC} | xstr -c -
@${CC} ${CPPFLAGS} ${CFLAGS} -c x.c -o ${.TARGET}
@rm -f x.c
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.cc.o .cpp.o .cxx.o .C.o:
${CXX} -E ${CPPFLAGS} ${CXXFLAGS} ${.IMPSRC} | xstr -c -
@mv -f x.c x.cc
@${CXX} ${CPPFLAGS} ${CXXFLAGS} -c x.cc -o ${.TARGET}
@rm -f x.cc
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(MKPIE) && (${MKPIE} != "no")
CFLAGS+= ${PIE_CFLAGS}
AFLAGS+= ${PIE_AFLAGS}
LDFLAGS+= ${PIE_LDFLAGS}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
CFLAGS+= ${COPTS}
OBJCFLAGS+= ${OBJCOPTS}
MKDEP_SUFFIXES?= .o .ln
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
# CTF preserve debug symbols
.if defined(MKDTRACE) && (${MKDTRACE} != "no") && (${CFLAGS:M-g} != "")
CTFFLAGS+= -g
CTFMFLAGS+= -g
.endif
# ELF platforms depend on crti.o, crtbegin.o, crtend.o, and crtn.o
.ifndef LIBCRTBEGIN
LIBCRTBEGIN= ${DESTDIR}/usr/lib/crti.o ${_GCC_CRTBEGIN}
.MADE: ${LIBCRTBEGIN}
.endif
.ifndef LIBCRTEND
LIBCRTEND= ${_GCC_CRTEND} ${DESTDIR}/usr/lib/crtn.o
.MADE: ${LIBCRTEND}
.endif
_SHLINKER= ${SHLINKDIR}/ld.elf_so
.ifndef LIBCRT0
LIBCRT0= ${DESTDIR}/usr/lib/crt0.o
.MADE: ${LIBCRT0}
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
##### Installed system library definitions
#
# E.g.
# LIBC?=${DESTDIR}/usr/lib/libc.a
# LIBX11?=${DESTDIR}/usr/X11R7/lib/libX11.a
# etc..
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
# NB: If you are a library here, add it in bsd.README
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.for _lib in \
Enable optional GCC install and GCC improvements -By adding MKGCC=yes and MKGCCCMDS=yes on the make commandline it is now possible to compile and install GCC on the system. Before doing this, if you are not using the build.sh script, you will need to call the fetch scripts in order to retrieve the sources of GCC and its dependencies. -Reduce difference with NetBSD share/mk Move Minix-specific parameters from bsd.gcc.mk to bsd.own.mk, which is anyway patched, so that bsd.gcc.mk is now aligned on the NetBSD version. -Clean libraries dependencies, compiles stdc++ only if gcc is also compiled (it is part of the gcc sources) -Correct minix.h header sequence, cleanup spec headers. -Fix cross-compilation from a 32bit host targeting MINIX/arm Change-Id: I1b234af18eed4ab5675188244e931b2a2b7bd943
2013-04-24 18:57:59 +02:00
atf_c \
atf_cxx \
bz2 \
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
c \
Enable optional GCC install and GCC improvements -By adding MKGCC=yes and MKGCCCMDS=yes on the make commandline it is now possible to compile and install GCC on the system. Before doing this, if you are not using the build.sh script, you will need to call the fetch scripts in order to retrieve the sources of GCC and its dependencies. -Reduce difference with NetBSD share/mk Move Minix-specific parameters from bsd.gcc.mk to bsd.own.mk, which is anyway patched, so that bsd.gcc.mk is now aligned on the NetBSD version. -Clean libraries dependencies, compiles stdc++ only if gcc is also compiled (it is part of the gcc sources) -Correct minix.h header sequence, cleanup spec headers. -Fix cross-compilation from a 32bit host targeting MINIX/arm Change-Id: I1b234af18eed4ab5675188244e931b2a2b7bd943
2013-04-24 18:57:59 +02:00
c_pic \
crt0 \
crypt \
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
curses \
edit \
expat \
l \
Enable optional GCC install and GCC improvements -By adding MKGCC=yes and MKGCCCMDS=yes on the make commandline it is now possible to compile and install GCC on the system. Before doing this, if you are not using the build.sh script, you will need to call the fetch scripts in order to retrieve the sources of GCC and its dependencies. -Reduce difference with NetBSD share/mk Move Minix-specific parameters from bsd.gcc.mk to bsd.own.mk, which is anyway patched, so that bsd.gcc.mk is now aligned on the NetBSD version. -Clean libraries dependencies, compiles stdc++ only if gcc is also compiled (it is part of the gcc sources) -Correct minix.h header sequence, cleanup spec headers. -Fix cross-compilation from a 32bit host targeting MINIX/arm Change-Id: I1b234af18eed4ab5675188244e931b2a2b7bd943
2013-04-24 18:57:59 +02:00
m \
magic \
rmt \
terminfo \
util \
z
.ifndef LIB${_lib:tu}
LIB${_lib:tu}= ${DESTDIR}/usr/lib/lib${_lib:S/xx/++/:S/atf_c/atf-c/}.a
.MADE: ${LIB${_lib:tu}} # Note: ${DESTDIR} will be expanded
.endif
.endfor
# Minix libraries
.for _lib in \
audiodriver \
bdev \
blockdriver \
chardriver \
elf \
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
exec \
ddekit \
devman \
minc \
minlib \
Enable optional GCC install and GCC improvements -By adding MKGCC=yes and MKGCCCMDS=yes on the make commandline it is now possible to compile and install GCC on the system. Before doing this, if you are not using the build.sh script, you will need to call the fetch scripts in order to retrieve the sources of GCC and its dependencies. -Reduce difference with NetBSD share/mk Move Minix-specific parameters from bsd.gcc.mk to bsd.own.mk, which is anyway patched, so that bsd.gcc.mk is now aligned on the NetBSD version. -Clean libraries dependencies, compiles stdc++ only if gcc is also compiled (it is part of the gcc sources) -Correct minix.h header sequence, cleanup spec headers. -Fix cross-compilation from a 32bit host targeting MINIX/arm Change-Id: I1b234af18eed4ab5675188244e931b2a2b7bd943
2013-04-24 18:57:59 +02:00
netdriver \
sffs \
sys \
timers \
usb
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.ifndef LIB${_lib:tu}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
LIB${_lib:tu}= ${DESTDIR}/usr/lib/lib${_lib:S/xx/++/:S/atf_c/atf-c/}.a
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.MADE: ${LIB${_lib:tu}} # Note: ${DESTDIR} will be expanded
.endif
.endfor
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
# PAM applications, if linked statically, need more libraries
.if (${MKPIC} == "no")
.if (${MKCRYPTO} != "no")
PAM_STATIC_LDADD+= -lssh
PAM_STATIC_DPADD+= ${LIBSSH}
.endif
.if (${MKKERBEROS} != "no")
PAM_STATIC_LDADD+= -lkafs -lkrb5 -lhx509 -lwind -lasn1 \
-lroken -lcom_err -lheimbase -lcrypto
PAM_STATIC_DPADD+= ${LIBKAFS} ${LIBKRB5} ${LIBHX509} ${LIBWIND} ${LIBASN1} \
${LIBROKEN} ${LIBCOM_ERR} ${LIBHEIMBASE} ${LIBCRYPTO}
.endif
.if (${MKSKEY} != "no")
PAM_STATIC_LDADD+= -lskey
PAM_STATIC_DPADD+= ${LIBSKEY}
.endif
PAM_STATIC_LDADD+= -lradius -lcrypt -lrpcsvc -lutil
PAM_STATIC_DPADD+= ${LIBRADIUS} ${LIBCRYPT} ${LIBRPCSVC} ${LIBUTIL}
.else
PAM_STATIC_LDADD=
PAM_STATIC_DPADD=
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
# NB: If you are a library here, add it in bsd.README
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.for _lib in \
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
FS \
GL \
GLU \
ICE \
SM \
X11 \
XTrap \
Xau \
Xaw \
Xdmcp \
Xext \
Xfont \
Xft \
Xi \
Xinerama \
Xmu \
Xmuu \
Xpm \
Xrandr \
Xrender \
Xss \
Xt \
Xtst \
Xv \
Xxf86dga \
Xxf86misc \
Xxf86vm \
dps \
fntstubs \
fontcache \
fontconfig \
fontenc \
freetype \
lbxutil \
xkbfile
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.ifndef LIB${_lib:tu}
LIB${_lib:tu}= ${DESTDIR}${X11USRLIBDIR}/lib${_lib}.a
.MADE: ${LIB${_lib:tu}} # Note: ${DESTDIR} will be expanded
.endif
.endfor
.if defined(RESCUEDIR)
CPPFLAGS+= -DRESCUEDIR=\"${RESCUEDIR}\"
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
_PROGLDOPTS=
.if ${SHLINKDIR} != "/usr/libexec" # XXX: change or remove if ld.so moves
_PROGLDOPTS+= -Wl,-dynamic-linker=${_SHLINKER}
.endif
.if ${SHLIBDIR} != "/usr/lib"
_PROGLDOPTS+= -Wl,-rpath,${SHLIBDIR} \
-L=${SHLIBDIR}
.elif ${SHLIBINSTALLDIR} != "/usr/lib"
_PROGLDOPTS+= -Wl,-rpath-link,${DESTDIR}${SHLIBINSTALLDIR} \
-L=${SHLIBINSTALLDIR}
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
__proginstall: .USE
${_MKTARGET_INSTALL}
${INSTALL_FILE} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Remove obsolete INSTALLFLAGS from makefiles
2012-02-16 23:26:38 +01:00
${STRIPFLAG} ${.ALLSRC} ${.TARGET}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
__progrumpinstall: .USE
${_MKTARGET_INSTALL}
${INSTALL_FILE} -o ${RUMPBINOWN} -g ${RUMPBINGRP} -m ${RUMPBINMODE} \
${STRIPFLAG} ${.ALLSRC} ${.TARGET}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
__progdebuginstall: .USE
${_MKTARGET_INSTALL}
${INSTALL_FILE} -o ${DEBUGOWN} -g ${DEBUGGRP} -m ${DEBUGMODE} \
Remove obsolete INSTALLFLAGS from makefiles
2012-02-16 23:26:38 +01:00
${.ALLSRC} ${.TARGET}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
#
# Backwards compatibility with Makefiles that assume that bsd.prog.mk
# can only build a single binary.
#
_APPEND_MANS=yes
_APPEND_SRCS=yes
_CCLINKFLAGS=
.if defined(PROG_CXX)
Enable optional GCC install and GCC improvements -By adding MKGCC=yes and MKGCCCMDS=yes on the make commandline it is now possible to compile and install GCC on the system. Before doing this, if you are not using the build.sh script, you will need to call the fetch scripts in order to retrieve the sources of GCC and its dependencies. -Reduce difference with NetBSD share/mk Move Minix-specific parameters from bsd.gcc.mk to bsd.own.mk, which is anyway patched, so that bsd.gcc.mk is now aligned on the NetBSD version. -Clean libraries dependencies, compiles stdc++ only if gcc is also compiled (it is part of the gcc sources) -Correct minix.h header sequence, cleanup spec headers. -Fix cross-compilation from a 32bit host targeting MINIX/arm Change-Id: I1b234af18eed4ab5675188244e931b2a2b7bd943
2013-04-24 18:57:59 +02:00
#.if defined(__MINIX) # LSC: Can't test as bsd.own.mk may not have been sourced
LDADD+= -lgcc_s
DPADD+= ${DESTDIR}/usr/lib/libgcc_s.a
#.endif # defined(__MINIX)
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
PROG= ${PROG_CXX}
_CCLINK= ${CXX} ${_CCLINKFLAGS}
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(RUMPPRG)
PROG= ${RUMPPRG}
. ifndef CRUNCHEDPROG
. if (${MKRUMP} != "no")
PROGS= ${RUMPPRG} rump.${RUMPPRG}
. else
PROGS= ${RUMPPRG}
. endif
. if defined(SRCS)
. if (${MKRUMP} != "no")
SRCS.rump.${PROG}:= ${SRCS} ${PROG}_rumpops.c ${RUMPSRCS}
. endif
SRCS+= ${PROG}_hostops.c
. else
SRCS= ${PROG}.c ${PROG}_hostops.c
. if (${MKRUMP} != "no")
SRCS.rump.${PROG}= ${PROG}.c ${PROG}_rumpops.c ${RUMPSRCS}
. endif
. endif
. if (${MKRUMP} != "no")
DPSRCS+= ${PROG}_rumpops.c ${RUMPSRCS}
LDADD.rump.${PROG}+= -lrumpclient
DPADD.rump.${PROG}+= ${LIBRUMPCLIENT}
MAN.rump.${PROG}= # defined but feeling empty
_RUMPINSTALL.rump.${PROG}=# defined
. endif
. else # CRUNCHEDPROG
PROGS= ${PROG}
CPPFLAGS+= -DCRUNCHOPS
. endif
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if defined(PROG)
_CCLINK?= ${CC} ${_CCLINKFLAGS}
. if defined(MAN)
MAN.${PROG}= ${MAN}
_APPEND_MANS= no
. endif
. if !defined(OBJS)
OBJS= ${OBJS.${PROG}}
. endif
. if defined(PROGNAME)
PROGNAME.${PROG}= ${PROGNAME}
. endif
. if defined(SRCS)
SRCS.${PROG}= ${SRCS}
_APPEND_SRCS= no
. endif
.endif
# Turn the single-program PROG and PROG_CXX variables into their multi-word
# counterparts, PROGS and PROGS_CXX.
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if !defined(RUMPPRG)
. if defined(PROG_CXX) && !defined(PROGS_CXX)
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
PROGS_CXX= ${PROG_CXX}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
. elif defined(PROG) && !defined(PROGS)
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
PROGS= ${PROG}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
. endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
#
# Per-program definitions and targets.
#
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
_CCLINK.CDEFAULT= ${CC} ${_CCLINKFLAGS}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
# Definitions specific to C programs.
.for _P in ${PROGS}
SRCS.${_P}?= ${_P}.c
_CCLINK.${_P}= ${CC} ${_CCLINKFLAGS}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
_CFLAGS.${_P}= ${CFLAGS} ${CPUFLAGS}
_CPPFLAGS.${_P}= ${CPPFLAGS}
_COPTS.${_P}= ${COPTS}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endfor
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
_CCLINK.CXXDEFAULT= ${CXX} ${_CCLINKFLAGS}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
# Definitions specific to C++ programs.
.for _P in ${PROGS_CXX}
SRCS.${_P}?= ${_P}.cc
_CCLINK.${_P}= ${CXX} ${_CCLINKFLAGS}
.endfor
# Language-independent definitions.
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
.if defined(__MINIX) && ${USE_BITCODE:Uno} == "yes"
CFLAGS+= -flto
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.for _P in ${PROGS} ${PROGS_CXX} # {
Gold linker support for entire source tree
2013-06-11 21:08:05 +02:00
.if defined(__MINIX) && ${HAVE_GOLD:U} != ""
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
Gold linker support for entire source tree
2013-06-11 21:08:05 +02:00
. if ${LD_STATIC:U} != "-static"
GOLDLINKERSCRIPT?= ${LDS_DYNAMIC_BIN}
. else
GOLDLINKERSCRIPT?= ${LDS_STATIC_BIN}
. endif
GOLDLINKERSCRIPT.${_P}?= ${GOLDLINKERSCRIPT}
. if ${GOLDLINKERSCRIPT.${_P}:U} != ""
LDFLAGS.${_P}:=-Wl,--script,${GOLDLINKERSCRIPT.${_P}} ${LDFLAGS.${_P}}
. endif
.endif # defined(__MINIX) && ${HAVE_GOLD:U} == ""
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
BINDIR.${_P}?= ${BINDIR}
PROGNAME.${_P}?= ${_P}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if ${MKDEBUG} != "no" && !commands(${_P})
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
_PROGDEBUG.${_P}:= ${PROGNAME.${_P}}.debug
.endif
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(PAXCTL_FLAGS)
PAXCTL_FLAGS.${_P}?= ${PAXCTL_FLAGS}
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
##### PROG specific flags.
Convert boot/ and commands/ over to bsdmake
2010-05-12 18:28:54 +02:00
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
_DPADD.${_P}= ${DPADD} ${DPADD.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
_LDADD.${_P}= ${LDADD} ${LDADD.${_P}}
_LDFLAGS.${_P}= ${LDFLAGS} ${LDFLAGS.${_P}}
_LDSTATIC.${_P}= ${LDSTATIC} ${LDSTATIC.${_P}}
##### Build and install rules
.if !empty(_APPEND_SRCS:M[Yy][Ee][Ss])
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
SRCS+= ${SRCS.${_P}} # For bsd.dep.mk
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
_YPSRCS.${_P}= ${SRCS.${_P}:M*.[ly]:C/\..$/.c/} ${YHEADER:D${SRCS.${_P}:M*.y:.y=.h}}
DPSRCS+= ${_YPSRCS.${_P}}
CLEANFILES+= ${_YPSRCS.${_P}}
.if !empty(SRCS.${_P}:N*.h:N*.sh:N*.fth)
OBJS.${_P}+= ${SRCS.${_P}:N*.h:N*.sh:N*.fth:R:S/$/.o/g}
LOBJS.${_P}+= ${LSRCS:.c=.ln} ${SRCS.${_P}:M*.c:.c=.ln}
.endif
.if defined(OBJS.${_P}) && !empty(OBJS.${_P}) # {
.NOPATH: ${OBJS.${_P}} ${_P} ${_YPSRCS.${_P}}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if (defined(USE_COMBINE) && ${USE_COMBINE} != "no" && !commands(${_P}) \
&& (${_CCLINK.${_P}} == ${_CCLINK.CDEFAULT} \
|| ${_CCLINK.${_P}} == ${_CCLINK.CXXDEFAULT}) \
&& !defined(NOCOMBINE.${_P}) && !defined(NOCOMBINE))
.for f in ${SRCS.${_P}:N*.h:N*.sh:N*.fth:C/\.[yl]$/.c/g}
#_XFLAGS.$f := ${CPPFLAGS.$f:D1} ${CPUFLAGS.$f:D2} \
# ${COPTS.$f:D3} ${OBJCOPTS.$f:D4} ${CXXFLAGS.$f:D5}
.if (${CPPFLAGS.$f:D1} == "1" || ${CPUFLAGS.$f:D2} == "2" \
|| ${COPTS.$f:D3} == "3" || ${OBJCOPTS.$f:D4} == "4" \
|| ${CXXFLAGS.$f:D5} == "5") \
|| ("${f:M*.[cyl]}" == "" || commands(${f:R:S/$/.o/}))
XOBJS.${_P}+= ${f:R:S/$/.o/}
.else
XSRCS.${_P}+= ${f}
NODPSRCS+= ${f}
.endif
.endfor
${_P}: .gdbinit ${LIBCRT0} ${XOBJS.${_P}} ${SRCS.${_P}} ${DPSRCS} ${LIBC} ${LIBCRTBEGIN} ${LIBCRTEND} ${_DPADD.${_P}}
${_MKTARGET_LINK}
.if defined(DESTDIR)
${_CCLINK.${_P}} -Wl,-nostdlib \
${_LDFLAGS.${_P}} ${_LDSTATIC.${_P}} -o ${.TARGET} ${_PROGLDOPTS} \
-B${_GCC_CRTDIR}/ -B${DESTDIR}/usr/lib/ \
-MD --combine ${_CPPFLAGS.${_P}} ${_CFLAGS.${_P}} ${_COPTS.${_P}} \
${XSRCS.${_P}:@.SRC.@${.ALLSRC:M*.c:M*${.SRC.}}@:O:u} ${XOBJS.${_P}} \
${_LDADD.${_P}} -L${_GCC_LIBGCCDIR} -L${DESTDIR}/usr/lib
.else
${_CCLINK.${_P}} ${_LDFLAGS.${_P}} ${_LDSTATIC.${_P}} -o ${.TARGET} ${_PROGLDOPTS} \
-MD --combine ${_CPPFLAGS.${_P}} ${_COPTS.${_P}}
${XSRCS.${_P}:@.SRC.@${.ALLSRC:M*.c:M*${.SRC.}}@:O:u} ${XOBJS.${_P}} \
${_LDADD.${_P}}
.endif # defined(DESTDIR)
.if defined(CTFMERGE)
${CTFMERGE} ${CTFMFLAGS} -o ${.TARGET} ${OBJS.${_P}}
.endif
.if defined(PAXCTL_FLAGS.${_P})
${PAXCTL} ${PAXCTL_FLAGS.${_P}} ${.TARGET}
.endif
.if ${MKSTRIPIDENT} != "no"
${OBJCOPY} -R .ident ${.TARGET}
.endif
CLEANFILES+= ${_P}.d
.if exists(${_P}.d)
.include "${_P}.d" # include -MD depend for program.
.endif
.else # USE_COMBINE
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${OBJS.${_P}} ${LOBJS.${_P}}: ${DPSRCS}
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
.if defined(__MINIX)
CLEANFILES+= ${_P}.opt.bcl ${_P}.bcl ${_P}.bcl.o
.endif # defined(__MINIX)
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if !commands(${_P})
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
.if ${USE_BITCODE:Uno} == "yes"
.if ${LLVM_PASS:UNO_PASS} != "NO_PASS"
_LLVM_PASS_ARGS= -load ${LLVM_PASS} ${LLVM_PASS_ARGS}
_TARGET_BCL= ${_P}.opt.bcl
.else
_TARGET_BCL= ${_P}.bcl
.endif # ${LLVM_PASS:UNO_PASS} != "NO_PASS"
${_P}.bcl: .gdbinit ${LIBCRT0} ${OBJS.${_P}} ${LIBC} ${LIBCRTBEGIN} ${LIBCRTEND} ${_DPADD.${_P}}
${_MKTARGET_LINK}
${_CCLINK.${_P}} \
-o ${.TARGET} \
-nostartfiles \
-L/usr/lib/bc \
${OBJS.${_P}} ${LLVM_LINK_ARGS} ${_LDADD.${_P}:N-shared} \
${_LDSTATIC.${_P}} \
-Wl,-r \
-Wl,-plugin=/usr/pkg/lib/bfd-plugins/LLVMgold.so,-plugin-opt=-disable-opt,-plugin-opt=-disable-inlining,-plugin-opt=emit-llvm
${_P}.opt.bcl: ${_P}.bcl ${LLVM_PASS}
${_MKTARGET_LINK}
opt -disable-opt ${_LLVM_PASS_ARGS} -o ${.TARGET} ${_P}.bcl
${_P}.bcl.o: ${_TARGET_BCL}
${_MKTARGET_LINK}
llc -O1 -filetype=obj -o ${.TARGET} ${.ALLSRC}
${_P}: ${_P}.bcl.o
${_MKTARGET_LINK}
${_CCLINK.${_P}} \
-o ${.TARGET} \
-L/usr/lib/bc \
${.TARGET}.bcl.o ${_LDADD.${_P}} \
${_LDSTATIC.${_P}} \
-Wl,--script,${GOLDLINKERSCRIPT.${_P}} \
-Wl,-plugin=/usr/pkg/lib/bfd-plugins/LLVMgold.so,-plugin-opt=-disable-opt,-plugin-opt=-disable-inlining
.else
${_P}: .gdbinit ${LIBCRT0} ${OBJS.${_P}} ${LIBC} ${LIBCRTBEGIN} ${LIBCRTEND} ${_DPADD.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${_MKTARGET_LINK}
${_CCLINK.${_P}} \
${_LDFLAGS.${_P}} ${_LDSTATIC.${_P}} -o ${.TARGET} \
${OBJS.${_P}} ${_LDADD.${_P}} \
${_PROGLDOPTS}
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
.endif # ${USE_BITCODE:Uno} == "yes"
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(CTFMERGE)
${CTFMERGE} ${CTFMFLAGS} -o ${.TARGET} ${OBJS.${_P}}
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if defined(PAXCTL_FLAGS.${_P})
${PAXCTL} ${PAXCTL_FLAGS.${_P}} ${.TARGET}
.endif
.if ${MKSTRIPIDENT} != "no"
${OBJCOPY} -R .ident ${.TARGET}
.endif
LLVM bitcode for almost the whole source tree Change-Id: Ibc6f89de112e0649c3a3bfe49c2baa2ed0746212
2013-06-17 16:51:49 +02:00
.else
${_P}: .gdbinit ${LIBCRT0} ${OBJS.${_P}} ${LIBC} ${LIBCRTBEGIN} ${LIBCRTEND} ${_DPADD.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif # !commands(${_P})
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.endif # USE_COMBINE
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
${_P}.ro: ${OBJS.${_P}} ${_DPADD.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${_MKTARGET_LINK}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
${CC} ${LDFLAGS} -nostdlib -r -Wl,-dc -o ${.TARGET} ${OBJS.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if defined(_PROGDEBUG.${_P})
${_PROGDEBUG.${_P}}: ${_P}
${_MKTARGET_CREATE}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
( ${OBJCOPY} --only-keep-debug ${_P} ${_PROGDEBUG.${_P}} \
&& ${OBJCOPY} --strip-debug -p -R .gnu_debuglink \
--add-gnu-debuglink=${_PROGDEBUG.${_P}} ${_P} \
) || (rm -f ${_PROGDEBUG.${_P}}; false)
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
.endif # defined(OBJS.${_P}) && !empty(OBJS.${_P}) # }
.if !defined(MAN.${_P})
MAN.${_P}= ${_P}.1
.endif # !defined(MAN.${_P})
.if !empty(_APPEND_MANS:M[Yy][Ee][Ss])
MAN+= ${MAN.${_P}}
.endif
realall: ${_P} ${_PROGDEBUG.${_P}}
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
CLEANFILES+= ${_P} ${_PROGDEBUG.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if defined(OBJS.${_P}) && !empty(OBJS.${_P})
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
CLEANFILES+= ${OBJS.${_P}} ${LOBJS.${_P}}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
_PROG_INSTALL+= proginstall-${_P}
.if !target(proginstall-${_P}) # {
proginstall-${_P}:: ${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}} \
${_PROGDEBUG.${_P}:D${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}}
.PRECIOUS: ${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}} \
${_PROGDEBUG.${_P}:D${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}}
.if ${MKUPDATE} == "no"
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(_RUMPINSTALL.${_P})
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}! ${_P} __progrumpinstall
.else
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}! ${_P} __proginstall
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if !defined(BUILD) && !make(all) && !make(${_P})
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}! .MADE
.endif
.if defined(_PROGDEBUG.${_P})
${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}! ${_PROGDEBUG.${_P}} __progdebuginstall
.if !defined(BUILD) && !make(all) && !make(${_P})
${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}! .MADE
.endif
.endif # define(_PROGDEBUG.${_P})
.else # MKUPDATE != no
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.if defined(_RUMPINSTALL.${_P})
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}: ${_P} __progrumpinstall
.else
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}: ${_P} __proginstall
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.endif
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.if !defined(BUILD) && !make(all) && !make(${_P})
${DESTDIR}${BINDIR.${_P}}/${PROGNAME.${_P}}: .MADE
.endif
.if defined(_PROGDEBUG.${_P})
${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}: ${_PROGDEBUG.${_P}} __progdebuginstall
.if !defined(BUILD) && !make(all) && !make(${_P})
${DESTDIR}${DEBUGDIR}${BINDIR.${_P}}/${_PROGDEBUG.${_P}}: .MADE
.endif
.endif # defined(_PROGDEBUG.${_P})
.endif # MKUPDATE != no
.endif # !target(proginstall-${_P}) # }
lint: lint-${_P}
lint-${_P}: ${LOBJS.${_P}}
.if defined(LOBJS.${_P}) && !empty(LOBJS.${_P})
${LINT} ${LINTFLAGS} ${_LDFLAGS.${_P}:C/-L[ ]*/-L/Wg:M-L*} ${LOBJS.${_P}} ${_LDADD.${_P}}
.endif
.endfor # _P in ${PROGS} ${PROGS_CXX} # }
.if defined(OBJS) && !empty(OBJS) && \
(empty(PROGS) && empty(PROGS_CXX))
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
CLEANFILES+= ${OBJS} ${LOBJS}
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
.endif
.if !target(proginstall)
proginstall:: ${_PROG_INSTALL}
.endif
.PHONY: proginstall
realall: ${SCRIPTS}
.if defined(SCRIPTS) && !target(scriptsinstall) # {
SCRIPTSDIR?=${BINDIR}
SCRIPTSOWN?=${BINOWN}
SCRIPTSGRP?=${BINGRP}
SCRIPTSMODE?=${BINMODE}
scriptsinstall:: ${SCRIPTS:@S@${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}@}
.PRECIOUS: ${SCRIPTS:@S@${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}@}
__scriptinstall: .USE
${_MKTARGET_INSTALL}
${INSTALL_FILE} \
-o ${SCRIPTSOWN_${.ALLSRC:T}:U${SCRIPTSOWN}} \
-g ${SCRIPTSGRP_${.ALLSRC:T}:U${SCRIPTSGRP}} \
-m ${SCRIPTSMODE_${.ALLSRC:T}:U${SCRIPTSMODE}} \
${.ALLSRC} ${.TARGET}
.for S in ${SCRIPTS:O:u}
.if ${MKUPDATE} == "no"
${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}! ${S} __scriptinstall
.if !defined(BUILD) && !make(all) && !make(${S})
${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}! .MADE
.endif
.else
${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}: ${S} __scriptinstall
.if !defined(BUILD) && !make(all) && !make(${S})
${DESTDIR}${SCRIPTSDIR_${S}:U${SCRIPTSDIR}}/${SCRIPTSNAME_${S}:U${SCRIPTSNAME:U${S:T:R}}}: .MADE
.endif
.endif
.endfor
.endif # }
.if !target(scriptsinstall)
scriptsinstall::
.endif
.PHONY: scriptsinstall
##### Pull in related .mk logic
LINKSOWN?= ${BINOWN}
LINKSGRP?= ${BINGRP}
LINKSMODE?= ${BINMODE}
Rename mkfiles from minix.*.mk to bsd.*.mk Makes things easier for pkgsrc
2010-06-25 20:29:09 +02:00
.include <bsd.man.mk>
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.include <bsd.nls.mk>
Rename mkfiles from minix.*.mk to bsd.*.mk Makes things easier for pkgsrc
2010-06-25 20:29:09 +02:00
.include <bsd.files.mk>
.include <bsd.inc.mk>
.include <bsd.links.mk>
.include <bsd.sys.mk>
.include <bsd.dep.mk>
Upgrading build system to new NetBSD revision The tested targets are the followgin ones: * tools * distribution * sets * release The remaining NetBSD targets have not been disabled nor tested *at all*. Try them at your own risk, they may reboot the earth. For all compliant Makefiles, objects and generated files are put in MAKEOBJDIR, which means you can now keep objects between two branch switching. Same for DESTDIR, please refer to build.sh options. Regarding new or modifications of Makefiles a few things: * Read share/mk/bsd.README * If you add a subdirectory, add a Makefile in it, and have it called by the parent through the SUBDIR variable. * Do not add arbitrary inclusion which crosses to another branch of the hierarchy; If you can't do without it, put a comment on why. If possible, do not use inclusion at all. * Use as much as possible the infrastructure, it is here to make life easier, do not fight it. Sets and package are now used to track files. We have one set called "minix", composed of one package called "minix-sys"
2012-09-12 09:37:05 +02:00
.include <bsd.clang-analyze.mk>
.include <bsd.clean.mk>
Incorporate bsdmake into buildsystem and reorganize libs
2010-02-16 15:41:33 +01:00
${TARGETS}: # ensure existence
.endif # HOSTPROG
Reference in a new issue Copy permalink