Add /.vscode/, .clang-format and .gdb_history to .gitignore because:
- For VSCode, workspace settings as well as debugging and task
configurations are stored at the root in a .vscode folder;
- For ClangFormat, the .clang-format file is searched relative to
the current working directory when reading stdin;
- For GDB, GDB command history file defaults to the value of the
environment variable GDBHISTFILE, or to ./.gdb_history if this
variable is not set.
Signed-off-by: Wang, Lei <lei4.wang@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221020171921.1078533-1-lei4.wang@intel.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
$PROJECT/.cache/clangd/index is the intended location for project index
data when using clangd as the language server. Ignore this directory to
keep the git status clean.
Signed-off-by: Wang, Lei <lei4.wang@intel.com>
Message-Id: <20220907150010.2047037-1-lei4.wang@intel.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
GNU Global is another tags engine which is more like cscope in being
able to support finding both references and definitions. You will be
un-surprised to know it also integrates well with Emacs.
The main benefit of integrating it into find-src-path is it takes less
time to rebuild the database from scratch when you have a lot of build
directories under your source tree.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210114165730.31607-3-alex.bennee@linaro.org>
Now that we always do out-of-tree builds (and the in-tree builds are
faked via a "build" directory), we can simplify out .gitignore file
quite a bit.
Message-Id: <20200909080305.258961-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
There is no need anymore to produce config-all-devices.mak, compute
the resulting dictionary directly instead of going through grepy.sh.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Meson requires the build dir to be separate from the source tree. Many
people are used to just running "./configure && make" though and the
meson conversion breaks that.
This introduces some backcompat support to make it appear as if an
"in source tree" build is being done, but with the results in the
"build/" directory. This allows "./configure && make" to work as it
did historically, albeit with the output binaries staying under build/.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
With Makefiles that have automatically generated dependencies, you
generated includes are set as dependencies of the Makefile, so that they
are built before everything else and they are available when first
building the .c files.
Alternatively you can use a fine-grained dependency, e.g.
target/arm/translate.o: target/arm/decode-neon-shared.inc.c
With Meson you have only one choice and it is a third option, namely
"build at the beginning of the corresponding target"; the way you
express it is to list the includes in the sources of that target.
The problem is that Meson decides if something is a source vs. a
generated include by looking at the extension: '.c', '.cc', '.m', '.C'
are sources, while everything else is considered an include---including
'.inc.c'.
Use '.c.inc' to avoid this, as it is consistent with our other convention
of using '.rst.inc' for included reStructuredText files. The editorconfig
file is adjusted.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
izzy2lost
Matt Borgerson
Wang, LeiandLaurent Vivier
Alex Bennée
Erik Abairandmborgerson
Viresh KumarandAlex Bennée
Thomas Debesseandmborgerson
Thomas HuthandLaurent Vivier
Paolo Bonzini
Daniel P. BerrangéandPaolo Bonzini