2018-01-03 06:17:27 +01:00
|
|
|
# Copyright (C) 2012-2018 Free Software Foundation, Inc.
|
On mainline/development, also link GDBserver with -lmcheck.
This factors --enable-libmcheck related bits from GDB's configure.ac
and makes GDBserver use them too. Specifically, the 'development'
global is moved to a separate script to it can be sourced by both GDB
and GDBserver, and the --enable-libmcheck/--disable-libmcheck bits
proper are moved to a new m4 file.
I started out by defining 'development' in the m4 file, but in the end
decided against it, as a separate script has the advantage that
changing it in release branches does not require regenerating
configure, unlike today.
I had also started out by making the new GDB_AC_LIBMCHECK itself
handle the yes/no default fallback depending on release/developement,
but since I had split out 'development' to a separate script, and, GDB
needs the python checks anyway (hence we'd need to do the python
checks in gdb's configure.ac, and pass in a 'default lmcheck yes/no'
parameter to GDB_AC_LIBMCHECK anyway), I ended up keeping
GDB_AC_LIBMCHECK isolated from the 'development' global. IOW, it's
the caller's business to handle it.
Tested on x86_64 Fedora 17. Built GDB and GDBserver with and without
--enable-libmcheck, and observed --enable-libmcheck overrides the
disablement of -lmcheck caused by python supporting threads, and that
GDBserver links with -lmcheck when expected. Also observed that
changing the 'development' global, and issuing "make" triggers a
relink, and '-lmcheck' is included or not from the link accordingly.
gdb/
2013-07-03 Pedro Alves <palves@redhat.com>
* Makefile.in (config.status): Depend on development.sh.
(aclocal_m4_deps): Add libmcheck.m4.
* acinclude.m4: Include libmcheck.m4.
* configure.ac: Source development.sh instead of setting
'development' here. --enable-libmcheck/--disable-libmcheck code
factored out to GDB_AC_LIBMCHECK. Run it.
* development.sh: New file.
* libmcheck.m4: New file.
* configure: Regenerate.
gdb/gdbserver/
2013-07-03 Pedro Alves <palves@redhat.com>
* Makefile.in (config.status): Depend on development.sh.
* acinclude.m4: Include libmcheck.m4.
* configure: Regenerate.
2013-07-03 15:25:46 +02:00
|
|
|
#
|
|
|
|
# This file is part of GDB.
|
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
Make it easy to make --disable-werror the default for both binutils and gdb
The goal of this patch is to provide an easy way to make
--disable-werror the default when building binutils, or the parts
of binutils that need to get built when building GDB. In development
mode, we want to continue making -Werror the default with GCC.
But, when making releases, I think we want to make it as easy as
possible for regular users to successfully build from sources.
GDB already has this kind of feature to turn -Werror as well as
the use of the libmcheck library. As GDB Release Manager, I take
advantage of it to turn those off after having cut the branch.
I'd like to be able to do the same for the binutils bits. And
perhaps Tristan will want to do the same for his releases too
(not sure, binutils builders might be a little savvier than GDB
builders).
This patch introduces a new file, called development.sh, which
just sets a variable called $development. In our development branches
(Eg. "master"), it's set to true. But setting it to false would allow
us to change the default behavior of various development-related
features to be turned off; in this case, it turns off the use of
-Werror by default (use --enable-werror to turn it back on).
bfd/ChangeLog:
* development.sh: New file.
* warning.m4 (AM_BINUTILS_WARNINGS): Source bfd/development.sh.
Make -Werror the default with GCC only if DEVELOPMENT is true.
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add
$(srcdir)/development.sh.
* Makefile.in, configure: Regenerate.
binutils/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gas/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gold/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): New.
* Makefile.in, configure: Regenerate.
gprof/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
ld/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
opcodes/ChangeLog:
* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
bfd's development.sh.
* Makefile.in, configure: Regenerate.
gdb/ChangeLog:
* development.sh: Delete.
* Makefile.in (config.status): Adjust dependency on development.sh.
* configure.ac: Adjust development.sh source call.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
* configure.ac: Adjust development.sh source call.
* Makefile.in (config.status): Adjust dependency on development.sh.
* configure: Regenerate.
Tested on x86_64-linux by building two ways: One with DEVELOPMENT
set to true, and one with DEVELOPMENT set to false. In the first
case, I could see the use of -Werror, while it disappeared in
the second case.
2014-05-19 23:46:01 +02:00
|
|
|
# Controls whether to enable development-mode features by default.
|
On mainline/development, also link GDBserver with -lmcheck.
This factors --enable-libmcheck related bits from GDB's configure.ac
and makes GDBserver use them too. Specifically, the 'development'
global is moved to a separate script to it can be sourced by both GDB
and GDBserver, and the --enable-libmcheck/--disable-libmcheck bits
proper are moved to a new m4 file.
I started out by defining 'development' in the m4 file, but in the end
decided against it, as a separate script has the advantage that
changing it in release branches does not require regenerating
configure, unlike today.
I had also started out by making the new GDB_AC_LIBMCHECK itself
handle the yes/no default fallback depending on release/developement,
but since I had split out 'development' to a separate script, and, GDB
needs the python checks anyway (hence we'd need to do the python
checks in gdb's configure.ac, and pass in a 'default lmcheck yes/no'
parameter to GDB_AC_LIBMCHECK anyway), I ended up keeping
GDB_AC_LIBMCHECK isolated from the 'development' global. IOW, it's
the caller's business to handle it.
Tested on x86_64 Fedora 17. Built GDB and GDBserver with and without
--enable-libmcheck, and observed --enable-libmcheck overrides the
disablement of -lmcheck caused by python supporting threads, and that
GDBserver links with -lmcheck when expected. Also observed that
changing the 'development' global, and issuing "make" triggers a
relink, and '-lmcheck' is included or not from the link accordingly.
gdb/
2013-07-03 Pedro Alves <palves@redhat.com>
* Makefile.in (config.status): Depend on development.sh.
(aclocal_m4_deps): Add libmcheck.m4.
* acinclude.m4: Include libmcheck.m4.
* configure.ac: Source development.sh instead of setting
'development' here. --enable-libmcheck/--disable-libmcheck code
factored out to GDB_AC_LIBMCHECK. Run it.
* development.sh: New file.
* libmcheck.m4: New file.
* configure: Regenerate.
gdb/gdbserver/
2013-07-03 Pedro Alves <palves@redhat.com>
* Makefile.in (config.status): Depend on development.sh.
* acinclude.m4: Include libmcheck.m4.
* configure: Regenerate.
2013-07-03 15:25:46 +02:00
|
|
|
development=true
|