Re: [proaudio] media-sound/ladish-1-r1 not building

[Karl Lindén <spray.sucks@xxxxxxxxx>]

2013/7/26 Wayne DePrince Jr. <waynedpj@xxxxxxxxxxx>:
> ahoy all,
>
>     it seems like ladish with USE python enabled is trying to pull in lash
> via pylash though i have -lash set for USE flags:
>
>>>> Emerging (9 of 21) media-sound/ladish-1-r1 from proaudio
>  * ladish-1.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
> [ ok ]
>>>> Unpacking source...
>>>> Unpacking ladish-1.tar.bz2 to
>>>> /var/tmp/portage/media-sound/ladish-1-r1/work
>>>> Source unpacked in /var/tmp/portage/media-sound/ladish-1-r1/work
>>>> Preparing source in
>>>> /var/tmp/portage/media-sound/ladish-1-r1/work/ladish-1 ...
>  * Applying ladish-1-include.patch ...
> [ ok ]
>>>> Source prepared.
>>>> Configuring source in
>>>> /var/tmp/portage/media-sound/ladish-1-r1/work/ladish-1 ...
> CCFLAGS="-march=native -O2 -pipe" LINKFLAGS="-Wl,-O1 -Wl,--as-needed"
> "/var/tmp/portage/media-sound/ladish-1-r1/work/ladish-1/waf" --prefix=/usr
> --enable-pylash configure
> Setting top to                           :
> /var/tmp/portage/media-sound/ladish-1-r1/work/ladish-1
> Setting out to                           :
> /var/tmp/portage/media-sound/ladish-1-r1/work/ladish-1/build
> Checking for 'gcc' (c compiler)          : ok
> Checking for 'g++' (c++ compiler)        : ok
> Checking for program python              : /usr/bin/python2.7
> python executable '/usr/bin/python2.7' different from sys.executable
> '/var/tmp/portage/media-sound/ladish-1-r1/temp/python2.7/bin/python'
> Checking for program msgfmt              : /usr/bin/msgfmt
> Checking for program perl                : /usr/bin/perl
> Checking for 'intltool-merge'            : /usr/bin/intltool-merge
> Checking for header locale.h             : yes
> Checking for libdl                       : yes
> Checking for libutil                     : yes
> Checking for program pkg-config          : /usr/bin/pkg-config
> Checking for 'jack'                      : yes
> Checking for 'alsa'                      : yes
> Checking for 'dbus-1' >= 1.0.0           : yes
> Retrieving D-Bus services dir            : yes
> Checking for 'uuid'                      : yes
> Checking for header expat.h              : yes
> Checking for 'glib-2.0'                  : yes
> Checking for 'dbus-glib-1'               : yes
> Checking for 'gtk+-2.0' >= 2.20.0        : yes
> Checking for 'flowcanvas' >= 0.6.4       : yes
> Checking for boost include path          : /usr/include (ver 1_53)
> pylash build was requested but liblash was not
>
> i am no ebuild expert and admittedly the problem could be with my setup, but
> looking at the ebuild i believe the error is in the following line in
> src_configure:
>
> $(usex python --enable-pylash "")
>
>
> it seems like using python implies using lash.  thus, would it make sense to
> have something like
>
> $(usex python "--enable-pylash --enable-liblash" "")
>
> or do the use flags need to be changed so enabling python also enables lash,
> maybe using REQUIRED_USE
>
> REQUIRED_USE="${PYTHON_REQUIRED_USE}
>      python? ( lash )"
>
>     basically, i am unclear about what the intention is: does the python USE
> flag only matter if lash is also enabled, or does enabling python w/o lash
> also make sense?  i am assuming the latter (i.e. that having python/pylash
> w/o lash does not make sense) and so i have attached a new ebuild where
> python USE flag only makes sense with the lash USE and thus has the above
> REQUIRED_USE to ensure that.
>
>     thanks in advance.
>
> peace, w
>

Hello!

Yes, I think you are right. I can't see any other possibility other
than pylash implies liblash, because the build system enforces it. I
mean, it would make no sense to build python bindings (pylash) for a
non-existent compatibility layer (liblash). Please do correct me if
I'm wrong here.

I'll definitely go with the REQUIRED_USE solution. Commited as
ladish-1-r2. The same applies to -9999-r1, but without revbump. Thank
you!

Regards,
Karl