Makefile: include generated hconf.c in distribution
As for lex and yacc generated files, also distribute the gperf-generated
file, as gperf is not always installed, and sometimes not the correct
version.
Reported-by: Freddie Chopin <freddie.chopin@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(cherry picked from commit 84325c33cecc2deef8085d2d9438fa7cc2e0cabb) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When we switched to a single top-level Makefile, we lost the ability
to build out-of-tree, but only in a non-git tree... Weird...
However, the error is real: we were missing a include path for the
generated files, wihch are not generated in top_srcdir but in
top_builddir.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(cherry picked from commit 5bb1084ddc395fe8b5193a3d85a4daa86fef49a4) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
New version of gperf (3.1, released in January 2017) breaks the
build of kconfig-frontends both for the last package you uploaded
(3.12.0.0) and for the HEAD from the repository.
The problem is that gperf 3.1 now uses "size_t" as the length
argument for the functions, while earlier versions use "unsigned
int".
As suggested by Freddie, add a configure check to detect the type used
in gperf declarations. Unlike the patch from Freddie, we use as much
autoconf code as possible, rather than canned shell commands. This makes
the code about twice bigger, but it is full autoconf stuff, so
presumably more portable.
Also add a patch to be applied by scripts/ksync.sh, so that the change
persists with future update from upstream (as so we catch it when
upstream fixes it by themselves).
Reported-by: Freddie Chopin <freddie.chopin@gmail.com> Inspired-by: https://gist.github.com/FreddieChopin/b2ec415ee4eacbd4b92499bbf4e934be Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(cherry picked from commit 095eba4a2c163f67bdc50dca7b75ca8895da6814) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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