History log of /freebsd-10.1-release/share/mk/bsd.crunchgen.mk
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 272461 02-Oct-2014 gjb

Copy stable/10@r272459 to releng/10.1 as part of
the 10.1-RELEASE process.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 270291 21-Aug-2014 emaste

MFC r264927 by imp:

NO_DEBUG_FILES -> MK_DEBUG_FILES=no in last remaining place.


# 256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


# 251512 07-Jun-2013 emaste

Add a new knob WITH_DEBUG_FILES to control the building of standalone
debug files for userland programs and libraries. The "-g" debug flag
is automatically applied when WITH_DEBUG_FILES is set.

The debug files are now named ${prog}.debug and ${shlib}.debug for
consistency with other systems and documentation. In addition they are
installed under /usr/lib/debug, to simplify the process of installing
them if needed after a crash. Users of bsd.{prog,lib}.mk outside of the
base system place the standalone debug files in a .debug subdirectory.
GDB automatically searches both of these directories for standalone
debug files.

Thanks to everyone who contributed changes, review, and testing during
development.


# 241298 06-Oct-2012 marcel

Add support for bmake. This includes:
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).

Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>


# 237574 25-Jun-2012 obrien

Ensure crunchen uses the same make binary as the rest of the build.

Submitted by: Simon Gerraty <sjg@juniper.net>


# 229658 05-Jan-2012 adrian

Allow crunchgen binary link generation to be disabled.

If CRUNCH_GENERATE_LINKS is set to "no", then no links will be
generated.

This defaults to "yes" so things like release crunch building
still works.


# 215413 16-Nov-2010 adrian

Re-enable generating links.


# 215226 13-Nov-2010 adrian

Break out the rules which generate crunchgen'ed binaries into a separate
.mk file so they can be reused.

Introduce a new option, CRUNCH_BUILDTOOLS, which lists the binaries that
require tools built in the local architecture. sh and csh both require this.
It was previously hardcoded in rescue/rescue/Makefile .

Introduce a new option, CRUNCH_SHLIBS, which lists the shared libraries
to link against. These override the static libraries listed in CRUNCH_LIBS.
Some build environments may wish to use a handful of shared libraries
(eg libc.so) so other small, dynamic binaries can be run in the environment.

Remove the now-shared code from rescue/rescue/Makefile and introduce the
CRUNCH_BUILDTOOLS option for the above shells.