giflib: don't depend on libsm if x11 is unavailable

If DISTRO_FEATURES doesn't contain x11, libsm is not available. As libsm is optional, the dependency is changed to be conditional. There's no need to alter configure flags, because without x11, libsm cannot be picked up accidentially. Because this just fixes a missing dependency failure without x11, no PR bump is required either.

Signed-off-by Andreas Oberritter <[email protected]>

---
 meta-oe/recipes-devtools/giflib/giflib_4.1.6.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

meta-oe/recipes-devtools/giflib/giflib_4.1.6.bb +1 -1

index bd7b495..4e782e2 100644
@@ -8,7 +8,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/giflib/${BP}.tar.bz2"
 
 inherit autotools
 
-DEPENDS = "libsm"
+DEPENDS = "${@base_contains('DISTRO_FEATURES', 'x11', 'libsm', '', d)}"
 
 PACKAGES += "${PN}-utils"
 FILES_${PN} = "${libdir}/libgif.so.*"

There's no need to alter configure flags, because without x11, libsm cannot be picked up accidentially. Because this just fixes a missing dependency failure without x11, no PR bump is required either.

Quoted 5 lines · Andreas Oberritter

There's no need to alter configure flags, because without x11, libsm cannot be picked up accidentially. Because this just fixes a missing dependency failure without x11, no PR bump is required either.

I do prefer a clear configure option depending on if it is going to use or not libsm otherwise if user has built it, it is going to be taken.

Also,
please PR bump in any case since it can help spot other possible failures that we'd not catch otherwise.

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Quoted 7 lines · Andreas Oberritter

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Can the user call:

bitbake libsm

and then build giflib? in case of positive, we need to enforce have or not it linked.

Quoted 10 lines · Otavio Salvador

Quoted 7 lines · Andreas Oberritter

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Quoted 6 lines

Can the user call:

bitbake libsm

and then build giflib? in case of positive, we need to enforce have or not it linked.

At the time I created the patch, the user couldn't run bitbake libsm (for the same reason that it wouldn't be built automatically through giflib's DEPENDS).

That said, I updated the repos after your mail and ran bitbake libsm in order to get the error message again, but the error vanished. Apparently, an indirect dependency on libx11 was dropped during the last few weeks. I searched the logs, but didn't find the change. Strange. Now, many x11 packages got built even though x11 still wasn't listed in my DISTRO_FEATURES.

Anyway, please consider this patch obsolete. I'll probably resend an updated version together with other patches to disable some more x11 libraries on demand.

1.) Pass --disable-x11 unconditionally like Debian/Ubuntu 2.) Add virtual/libx11 to DEPENDS, if x11 is defined in DISTRO_FEATURES, and add --enable/diable-x11 to EXTRA_OECONF

Because the current recipe didn't depend on libX11 and no one complained about it, I question the usefulness of linking giflib against x11. Therefore I vote for option 1 (see patch below).

Quoted 2 lines · Andreas Oberritter

Quoted 1 line · Otavio Salvador

On Wed, Feb 8, 2012 at 17:35, Andreas Oberritter

Quoted 26 lines

Quoted 7 lines

Quoted 6 lines

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Quoted 7 lines

Can the user call:

bitbake libsm

and then build giflib? in case of positive, we need to enforce have or not
it linked.

At the time I created the patch, the user couldn't run bitbake libsm (for the same reason that it wouldn't be built automatically through giflib's DEPENDS).

That said, I updated the repos after your mail and ran bitbake libsm in order to get the error message again, but the error vanished. Apparently, an indirect dependency on libx11 was dropped during the last few weeks. I searched the logs, but didn't find the change. Strange. Now, many x11 packages got built even though x11 still wasn't listed in my DISTRO_FEATURES.

Quoted 3 lines

Anyway, please consider this patch obsolete. I'll probably resend an updated version together with other patches to disable some more x11 libraries on demand.

I did some further research regarding giflib:

- giflib doesn't depend on libSM alone, but optionally depends on libX11. When linked against libX11, it also links agains libSM and libICE, under certain conditions. Since libSM does not depend on libX11, the current giflib build is non-deterministic.

- Debian's/Ubuntu's giflib gets configured with --disable-x11 unconditionally.

So we have two options:

1.) Pass --disable-x11 unconditionally like Debian/Ubuntu 2.) Add virtual/libx11 to DEPENDS, if x11 is defined in DISTRO_FEATURES, and add --enable/diable-x11 to EXTRA_OECONF

Because the current recipe didn't depend on libX11 and no one complained about it, I question the usefulness of linking giflib against x11. Therefore I vote for option 1 (see patch below).

What does giflib do if linked against libX11?
- It builds a tool called gif2x11
- DumpScreen2Gif() gains support for dumping X11 windows

Quoted 2 lines · Andreas Oberritter

Quoted 1 line · Otavio Salvador

On Wed, Feb 8, 2012 at 17:35, Andreas Oberritter

Quoted 26 lines

Quoted 7 lines

Quoted 6 lines

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Quoted 7 lines

Can the user call:

bitbake libsm

and then build giflib? in case of positive, we need to enforce have or not
it linked.

At the time I created the patch, the user couldn't run bitbake libsm (for the same reason that it wouldn't be built automatically through giflib's DEPENDS).

That said, I updated the repos after your mail and ran bitbake libsm in order to get the error message again, but the error vanished. Apparently, an indirect dependency on libx11 was dropped during the last few weeks. I searched the logs, but didn't find the change. Strange. Now, many x11 packages got built even though x11 still wasn't listed in my DISTRO_FEATURES.

Quoted 3 lines

Anyway, please consider this patch obsolete. I'll probably resend an updated version together with other patches to disable some more x11 libraries on demand.

I did some further research regarding giflib:

- giflib doesn't depend on libSM alone, but optionally depends on libX11. When linked against libX11, it also links agains libSM and libICE, under certain conditions. Since libSM does not depend on libX11, the current giflib build is non-deterministic.

- Debian's/Ubuntu's giflib gets configured with --disable-x11 unconditionally.

So we have two options:

1.) Pass --disable-x11 unconditionally like Debian/Ubuntu 2.) Add virtual/libx11 to DEPENDS, if x11 is defined in DISTRO_FEATURES, and add --enable/diable-x11 to EXTRA_OECONF

Because the current recipe didn't depend on libX11 and no one complained about it, I question the usefulness of linking giflib against x11. Therefore I vote for option 1 (see patch below).

What does giflib do if linked against libX11?
- It builds a tool called gif2x11
- DumpScreen2Gif() gains support for dumping X11 windows

I'd agree with disabling it as well. According to google it was Henning who added libsm as a dependency in OE-Classic. Henning, do you remember the reason for adding this, and is it still valid?

Cheers,
Paul

Quoted 30 lines · Otavio Salvador

Quoted 11 lines

Quoted 7 lines · Andreas Oberritter

I already explained in the commit message, why a PR bump is not needed. Can you please explain which other possible failures you're expecting, so I can learn why my reasoning may be wrong?

This patch only fixes an unavailable build dependency at bitbake level, nothing more.

Quoted 6 lines

Can the user call:

bitbake libsm

and then build giflib? in case of positive, we need to enforce have or not it linked.

At the time I created the patch, the user couldn't run bitbake libsm (for the same reason that it wouldn't be built automatically through giflib's DEPENDS).

That said, I updated the repos after your mail and ran bitbake libsm in order to get the error message again, but the error vanished. Apparently, an indirect dependency on libx11 was dropped during the last few weeks. I searched the logs, but didn't find the change. Strange. Now, many x11 packages got built even though x11 still wasn't listed in my DISTRO_FEATURES.

Quoted 3 lines

Anyway, please consider this patch obsolete. I'll probably resend an updated version together with other patches to disable some more x11 libraries on demand.

I did some further research regarding giflib:

- giflib doesn't depend on libSM alone, but optionally depends on libX11. When linked against libX11, it also links agains libSM and libICE, under certain conditions. Since libSM does not depend on libX11, the current giflib build is non-deterministic.

- Debian's/Ubuntu's giflib gets configured with --disable-x11 unconditionally.

So we have two options:

1.) Pass --disable-x11 unconditionally like Debian/Ubuntu 2.) Add virtual/libx11 to DEPENDS, if x11 is defined in DISTRO_FEATURES, and add --enable/diable-x11 to EXTRA_OECONF