Yann E. MORIN [Tue, 29 Nov 2016 20:25:48 +0000 (21:25 +0100)]
buildsystem: fix GEN messages in verbose mode
So far, setting silent mode was done in configure.ac, and was on by
default for "release" builds and off for "devel" builds.
However, in "release" builds, running "make V=1" would not display the
commands used to generate tsome files (like the ones generated via moc
or sed), because the MAKEFLAGS would always contain -s and it was not
possible to disable this behaviour unless by calling configure again.
Handle the SILENT_MAKEFLAGS like AM_V_GEN et al. are managed, by
diverting it to the correct value without the need to re-run configure.
At the same time, also provide the verbose versions of AM_V_MOC and
AM_V_GPERF (even if that is technically not needed, it's good for
homogeneity with the rest of the automake-generated code).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN [Tue, 23 Aug 2016 18:00:24 +0000 (20:00 +0200)]
buildsystem: don't use recursive make for kconfig meta frontend
Yet anotehr step to get rid of the recursive make.
We're now defining more than one bin_SCRIPT, so use += when assigning to
it. This also requires it be at least assinged once with =. Do that with
an empty value. Do so also for a few other variables.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN [Wed, 3 Aug 2016 19:15:53 +0000 (21:15 +0200)]
buildsystem: do not use program-prefix to set the kconfig- prefix
Currently, we use automake's --program-prefix to set the prefix of the
kconfig executables to 'kconfig-'.
However, this is neither very nice nor very reliable. In some cases, the
standard practice distributions use is to force the prefix to be empty,
in which case this would create clashes with other tools (esp. diff and
merge).
Furthermore, we use a dirty trick to achieve this, by initialising
program-prefix before initialising automake. There is no guarantee this
will continue to work with future automake versions.
Stop using this trick, and directly include the 'kconfig-' prefix for
all programs (binaries and scripts alike) that we may generate and
install.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN [Wed, 3 Aug 2016 17:49:52 +0000 (19:49 +0200)]
docs: remove known issues known to be resolved.
Some known issues are now known to be resolved:
- qconf now uses Qt5, so the Qt4 issue no longer applies (but there
may well be other Qt5-related issues; this would have to be tested:
I now no longer have access to a Cygwin setup);
- the MacOS X uninitialized jump variable has been fixed upstream.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN [Sun, 29 Nov 2015 21:04:32 +0000 (22:04 +0100)]
autostuff: get rid of the bootstrap script
Running autoreconf when AC_CONFIG_MACRO_DIR does not exist ends up in a
failure. Unfortunately, git does not track empty directories. That's why
we have bootstrap, which creates it before running autoreconf.
Add an empty, dummy file in there and track it, so we can get rid of our
bootstrap script.
Update the README file accordingly.
We're left with a stray, generated autom4te.cache file, but that's a
minor annoyance.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Configure: check for lex/yacc availability in path
Autoconf provides macros to check for `Particular programs'. Among
those are `lex' and `yacc' families of programs. When the relevant
macro is used, autoconf will look for a list of programs in the PATH,
perform execution check of the programs found, and set the associated
variable to the best possible match (for example, `flex' has precedence
over `lex').
The problem comes from the behavior of those two macros when no match
is found in the PATH: associated variables are set to a default value
and no further check is performed. This can lead to running ./configure
successfully and encountering an obfuscated error during compilation
for the output of `lex' and `yacc' could not be produced and fed to
the compiler.
This patch adds checks on the result of autoconf macros, and aborts
./configure execution if needed.
Signed-off-by: Clement Chauplannaz <chauplac@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Explicit the behavior regarding silent-rules (i.e. on by default for
release / off by default for development).
Correct a typo in the comment on -Werror option.
Signed-off-by: Clement Chauplannaz <chauplac@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Rewrite calls to `sed' to remove '-r/--regexp-extended' parameter, which is not
supported by BSD `sed'.
BSD `sed' does implement regular expressions, but enables them with parameter
'-E' which in turn is not officially supported by GNU `sed' - in fact it is
implemented but not documented.
Signed-off-by: Clement Chauplannaz <chauplac@gmail.com>
[yann.morin.1998@free.fr: tweak the root-menu hunk] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Yann E. MORIN" [Tue, 5 Mar 2013 00:08:27 +0000 (01:08 +0100)]
configure: also search for libtinfo if needed
As Justin says:
When building ncurses with --with-termlib several symbols get moved from
libncurses.so to libtinfo.so. Thus when linking with libncurses.so, one
additionally needs to link with libtinfo.so.
Contrary to the Linux kernel (that is on the verge of using pkg-config or
the ncurses*-config scripts), we simply see if we need to link against
libtinfo to get a symbol known to get moved there.
Reported-by: Justin <jlec@gentoo.org> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN" [Mon, 4 Mar 2013 23:29:51 +0000 (00:29 +0100)]
configure: fixup extended colors in wide-char-enabled ncurses
As Krzysztof puts it in its commit log in the Linux kernel:
The ncurses library allows for extended colors. The support for extended
colors support depends on wide-character support. ncurses headers
enable extended colors (NCURSES_EXT_COLORS) only when wide-character
support is enabled (NCURSES_WIDECHAR).
The "make menuconfig" uses wide-character ncursesw library, which can be
compiled with wide-character support, but does not define NCURSES_WIDECHAR
and it's using headers without wide-character (and extended colors) support.
This fixes problems with colors on systems with enabled extended colors
(like PLD Linux). Without this patch "make menuconfig" is hard to use.
In kconfig-frontends, we fix this by adding the appropriate CPPFLAGS to the
mconf-specific ncurses CPPFLAGS.
Reported-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN" [Mon, 4 Mar 2013 22:32:54 +0000 (23:32 +0100)]
Synchronise with v3.9-rc1
This brings up all changes accumulated since v3.7 was released:
- get the "CONFIG_" prefix from the environment
- enhancements in mconf: navigable input boxes, better UI, fix in lxdialog
- enhancements in nconf: entirely rewritten help texts, UI tweaks
- fixes in qconf and conf
- fix in documentation
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN" [Sat, 26 Jan 2013 18:00:32 +0000 (19:00 +0100)]
configure: build with -Werror by default for devel
When building a devel snapshot (eg. a checkout if the repo), build
with -Werror by default, unles overriden by the user. This should
hopefully help catch errors early.
For releases, do not build with -Werror by default, unless the user
explicitly request -Werror.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann E. MORIN" [Sun, 13 Jan 2013 22:10:48 +0000 (23:10 +0100)]
configure: dump checks for standard headers/functions
As Jan puts it:
I would simply direct users to read the compiler error message.
That enhances (hopefully) both their knowledge on compiling,
and reduces the walltime configure runs.
Make it so! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Jan Engelhardt <jengelh@inai.de>
projects / kconfig-frontends / log