You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

137 lines
3.0 KiB

build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
project('dtc', 'c',
version: files('VERSION.txt'),
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
license: ['GPL2+', 'BSD-2'],
default_options: 'werror=true',
meson_version: '>=0.57.0'
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
)
cc = meson.get_compiler('c')
add_project_arguments(
cc.get_supported_arguments([
'-Wpointer-arith',
'-Wcast-qual',
'-Wnested-externs',
'-Wstrict-prototypes',
'-Wmissing-prototypes',
'-Wredundant-decls',
'-Wshadow',
'-Wsuggest-attribute=format',
'-Wwrite-strings',
]),
language: 'c'
)
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
add_project_arguments(
'-DFDT_ASSUME_MASK=' + get_option('assume-mask').to_string(),
language: 'c'
)
if get_option('static-build')
static_build = true
extra_link_args = ['-static']
else
static_build = false
extra_link_args = []
endif
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
yamltree = 'yamltree.c'
yaml = dependency('yaml-0.1', version: '>=0.2.3', required: get_option('yaml'), static: static_build)
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
if not yaml.found()
add_project_arguments('-DNO_YAML', language: 'c')
yamltree = []
endif
valgrind = dependency('valgrind', required: get_option('valgrind'))
if not valgrind.found()
add_project_arguments('-DNO_VALGRIND', language: 'c')
endif
py = import('python')
py = py.find_installation(required: get_option('python'))
swig = find_program('swig', required: get_option('python'))
pylibfdt_enabled = not meson.is_cross_build() and py.found() and swig.found() ? true : false
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
version_gen_h = vcs_tag(
command: ['git', 'describe', '--dirty=+'],
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
input: 'version_gen.h.in',
output: 'version_gen.h',
)
subdir('libfdt')
dtc_tools = []
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
if get_option('tools')
flex = find_program('flex', required: true)
bison = find_program('bison', required: true)
util_dep = declare_dependency(
sources: ['util.c', version_gen_h],
include_directories: '.',
dependencies: libfdt_dep
)
lgen = generator(
flex,
output: '@PLAINNAME@.lex.c',
arguments: ['-o', '@OUTPUT@', '@INPUT@'],
)
pgen = generator(
bison,
output: ['@BASENAME@.tab.c', '@BASENAME@.tab.h'],
arguments: ['@INPUT@', '--defines=@OUTPUT1@', '--output=@OUTPUT0@'],
)
if cc.check_header('fnmatch.h')
dtc_tools += executable(
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
'convert-dtsv0',
[
lgen.process('convert-dtsv0-lexer.l'),
'srcpos.c',
],
dependencies: util_dep,
install: true,
link_args: extra_link_args,
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
)
endif
dtc_tools += executable(
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
'dtc',
[
lgen.process('dtc-lexer.l'),
pgen.process('dtc-parser.y'),
'checks.c',
'data.c',
'dtc.c',
'flattree.c',
'fstree.c',
'livetree.c',
'srcpos.c',
'treesource.c',
yamltree,
],
dependencies: [util_dep, yaml],
install: true,
link_args: extra_link_args,
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
)
foreach e: ['fdtdump', 'fdtget', 'fdtput', 'fdtoverlay']
dtc_tools += executable(e, files(e + '.c'), dependencies: util_dep, install: true, link_args: extra_link_args)
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
endforeach
install_data(
'dtdiff',
install_dir: get_option('prefix') / get_option('bindir'),
install_mode: 'rwxr-xr-x',
)
endif
if pylibfdt_enabled
subdir('pylibfdt')
endif
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
if get_option('tests')
subdir('tests')
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
endif