[PATCH] travis.yml: Use the libfdt from the distro instead of the submodule

[PATCH] travis.yml: Use the libfdt from the distro instead of the submodule

[Thomas Huth]

No need to compile-test third party submodules over and over again if
we can simply use the pre-build library from the distribution instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 .travis.yml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index fb3baabca9..e24c99fdb9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -128,6 +128,7 @@ jobs:
           - libbrlapi-dev
           - libcacard-dev
           - libcap-ng-dev
+          - libfdt-dev
           - libgcrypt20-dev
           - libgnutls28-dev
           - libgtk-3-dev
@@ -162,6 +163,7 @@ jobs:
           - libbrlapi-dev
           - libcacard-dev
           - libcap-ng-dev
+          - libfdt-dev
           - libgcrypt20-dev
           - libgnutls28-dev
           - libgtk-3-dev
@@ -195,6 +197,7 @@ jobs:
           - libbrlapi-dev
           - libcacard-dev
           - libcap-ng-dev
+          - libfdt-dev
           - libgcrypt20-dev
           - libgnutls28-dev
           - libgtk-3-dev
@@ -237,6 +240,7 @@ jobs:
           - libattr1-dev
           - libcacard-dev
           - libcap-ng-dev
+          - libfdt-dev
           - libgnutls28-dev
           - libiscsi-dev
           - liblttng-ust-dev
@@ -281,6 +285,7 @@ jobs:
           - libbrlapi-dev
           - libcacard-dev
           - libcap-ng-dev
+          - libfdt-dev
           - libgcrypt20-dev
           - libgnutls28-dev
           - libgtk-3-dev
-- 
2.31.1

Re: [PATCH] travis.yml: Use the libfdt from the distro instead of the submodule

[Philippe Mathieu-Daudé]

On 19/1/23 14:55, Thomas Huth wrote:
> No need to compile-test third party submodules over and over again if
> we can simply use the pre-build library from the distribution instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>   .travis.yml | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index fb3baabca9..e24c99fdb9 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -128,6 +128,7 @@ jobs:
>             - libbrlapi-dev
>             - libcacard-dev
>             - libcap-ng-dev
> +          - libfdt-dev
>             - libgcrypt20-dev
>             - libgnutls28-dev
>             - libgtk-3-dev

Could we remove cloning the submodule in the 'enabled' case now?
See ./configure:

1518  case "$fdt" in
1519    auto | enabled | internal)
1520       # Simpler to always update submodule, even if not needed.
1521       git_submodules="${git_submodules} dtc"
1522       ;;
1523  esac

Re: [PATCH] travis.yml: Use the libfdt from the distro instead of the submodule

[Thomas Huth]

On 19/01/2023 16.03, Philippe Mathieu-Daudé wrote:
> On 19/1/23 14:55, Thomas Huth wrote:
>> No need to compile-test third party submodules over and over again if
>> we can simply use the pre-build library from the distribution instead.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   .travis.yml | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index fb3baabca9..e24c99fdb9 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -128,6 +128,7 @@ jobs:
>>             - libbrlapi-dev
>>             - libcacard-dev
>>             - libcap-ng-dev
>> +          - libfdt-dev
>>             - libgcrypt20-dev
>>             - libgnutls28-dev
>>             - libgtk-3-dev
> 
> Could we remove cloning the submodule in the 'enabled' case now?
> See ./configure:
> 
> 1518  case "$fdt" in
> 1519    auto | enabled | internal)
> 1520       # Simpler to always update submodule, even if not needed.
> 1521       git_submodules="${git_submodules} dtc"
> 1522       ;;
> 1523  esac

I think currently "enabled" still means either "internal" or "system" ? ... 
so since we cannot know here yet whether there is a usable libfdt installed 
available or not, we cannot remove this yet.

If we want to avoid the unnecessary git cloning, we have to explicitly use 
--enable-fdt=system ... which would make sense here, indeed. I'll send a v2 
with that added.

  Thomas