Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-23 Thread Michał Górny
Dnia 2014-05-05, o godz. 10:29:12
Michał Górny mgo...@gentoo.org napisał(a):

 2. adds ${MULTILIB_ABI} variable to foreach loops that contains the flag
 matching currently iterated ABI.
 
 e.g.:
 
   ${ABI} == amd64
   ${MULTILIB_ABI} == abi_x86_64

Committed as MULTILIB_ABI_FLAG to avoid collision with ${MULTILIB_ABI}
used by multilib portage  confusion with ${MULTILIB_ABIS}.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-23 Thread Bertrand Jacquin

On 2014-05-23 09:55, Michał Górny wrote:

Dnia 2014-05-05, o godz. 10:29:12
Michał Górny mgo...@gentoo.org napisał(a):

2. adds ${MULTILIB_ABI} variable to foreach loops that contains the 
flag

matching currently iterated ABI.

e.g.:

  ${ABI} == amd64
  ${MULTILIB_ABI} == abi_x86_64


Committed as MULTILIB_ABI_FLAG to avoid collision with ${MULTILIB_ABI}
used by multilib portage  confusion with ${MULTILIB_ABIS}.


Thank you Michał !



Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-05 Thread Ulrich Mueller
 On Mon, 5 May 2014, Michał Górny wrote:

 Three quick patches for review:

 1. adds multilib_get_enabled_abi_pairs() as a replacement for
 multilib_get_enabled_abis(). The latter returned just the value
 of ${ABI}, the new function returns ${use_flag}:${ABI} pairs.

 e.g.:

   multilib_get_enabled_abis: x86 amd64
   multilib_get_enabled_abi_pairs: abi_x86_32:x86 abi_x86_64:amd64

These will get included in the pathname of the build dir, right?

If yes, are you sure that all upstream build systems can cope with
the colon in path names? I'd rather suggest to stay within the POSIX
portable filename character set (i.e. [A-Za-z0-9._-]).

Ulrich


pgpyxOts5zQqS.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-05 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/05/14 04:29 AM, Michał Górny wrote:

 3. deprecates multilib_for_best_abi() since having two separate 
 concepts of 'best ABI' and 'default ABI' is confusing, and mostly 
 doesn't serve any real purpose.
 
 For improved consistency, we would like people to use
 multilib-minimal and multilib_is_native_abi() tests if necessary.
 
 
 I will submit the patches in replies to this mail.
 

multilib_for_best_abi was introduced to deprecate
multilib_is_native_abi though, aren't we going backwards?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlNnkOwACgkQ2ugaI38ACPDY/QD7BobGgWFjbKt7FAfHd1aRFoOx
01drmn7eg50Pz6ICLY0A/29oqW21Qocf5rKLhLiE+cfRBFRoLow/4To6Gq0pFa5B
=we6c
-END PGP SIGNATURE-



Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-05 Thread Michał Górny
Dnia 2014-05-05, o godz. 11:02:33
Ulrich Mueller u...@gentoo.org napisał(a):

  On Mon, 5 May 2014, Michał Górny wrote:
 
  Three quick patches for review:
 
  1. adds multilib_get_enabled_abi_pairs() as a replacement for
  multilib_get_enabled_abis(). The latter returned just the value
  of ${ABI}, the new function returns ${use_flag}:${ABI} pairs.
 
  e.g.:
 
multilib_get_enabled_abis: x86 amd64
multilib_get_enabled_abi_pairs: abi_x86_32:x86 abi_x86_64:amd64
 
 These will get included in the pathname of the build dir, right?
 
 If yes, are you sure that all upstream build systems can cope with
 the colon in path names? I'd rather suggest to stay within the POSIX
 portable filename character set (i.e. [A-Za-z0-9._-]).

I was wondering about that in the morning but thought mostly of Windows
and decided we don't need to care. But now that I think of it, I can
think of ${PATH} and similar colon-separated variables.

I should probably use '.' then, since it's both more distinct than '-'
and disallowed in USE flags. Possibly stripping ':*' in multibuild could
result in more elegant paths but I don't want to introduce any other
special rules to follow.

Which makes me think that I need to check that no ebuild assumes
${S%/}-${ABI}.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-05 Thread Michał Górny
Dnia 2014-05-05, o godz. 09:23:56
Ian Stakenvicius a...@gentoo.org napisał(a):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 05/05/14 04:29 AM, Michał Górny wrote:
 
  3. deprecates multilib_for_best_abi() since having two separate 
  concepts of 'best ABI' and 'default ABI' is confusing, and mostly 
  doesn't serve any real purpose.
  
  For improved consistency, we would like people to use
  multilib-minimal and multilib_is_native_abi() tests if necessary.
  
  
  I will submit the patches in replies to this mail.
  
 
 multilib_for_best_abi was introduced to deprecate
 multilib_is_native_abi though, aren't we going backwards?

Honestly, I don't remember why it was introduced. I just checked
the commit message and relevant mails, and it's all quite laconic.
It was introduced as part of multibuild_for_best_variant(), and that
benefited mostly distutils-r1 for its *_all() phases.

I think multilib_for_best_abi() was mostly intended to help getting
autotools-multilib to work properly. Now it is built on top of
multilib-minimal, and people are encouraged to redefine the multilib_*
phases rather than try to hack on top of 'autotools-utils_src_compile'
and stuff. This makes most of multilib_for_best_abi() irrelevant.

So, I don't think we are really going backwards here. We've changed
direction over the past year. We've seen what caught better and I'm
mostly trying to make things simpler. As part of that, I'd like to
remove redundant APIs and focus on supporting one best-supported
interface for multilib. At the point, multilib-minimal seems to be
the way forward.

Do you agree with me on this? Do you have another ideas?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value deprecating multilib_for_best_abi()

2014-05-05 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/05/14 01:42 PM, Michał Górny wrote:
 Dnia 2014-05-05, o godz. 09:23:56 Ian Stakenvicius a...@gentoo.org
 napisał(a):
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 05/05/14 04:29 AM, Michał Górny wrote:
 
 3. deprecates multilib_for_best_abi() since having two separate
  concepts of 'best ABI' and 'default ABI' is confusing, and
 mostly doesn't serve any real purpose.
 
 For improved consistency, we would like people to use 
 multilib-minimal and multilib_is_native_abi() tests if
 necessary.
 
 
 I will submit the patches in replies to this mail.
 
 
 multilib_for_best_abi was introduced to deprecate 
 multilib_is_native_abi though, aren't we going backwards?
 
 Honestly, I don't remember why it was introduced. I just checked 
 the commit message and relevant mails, and it's all quite laconic. 
 It was introduced as part of multibuild_for_best_variant(), and
 that benefited mostly distutils-r1 for its *_all() phases.
 
 I think multilib_for_best_abi() was mostly intended to help
 getting autotools-multilib to work properly. Now it is built on top
 of multilib-minimal, and people are encouraged to redefine the
 multilib_* phases rather than try to hack on top of
 'autotools-utils_src_compile' and stuff. This makes most of
 multilib_for_best_abi() irrelevant.
 
 So, I don't think we are really going backwards here. We've
 changed direction over the past year. We've seen what caught better
 and I'm mostly trying to make things simpler. As part of that, I'd
 like to remove redundant APIs and focus on supporting one
 best-supported interface for multilib. At the point,
 multilib-minimal seems to be the way forward.
 
 Do you agree with me on this? Do you have another ideas?
 

Nope, this makes sense now.  I have a sneaky suspicion that my memory
had some cross-talk between multilib_for_best_abi and
multilib_build_binaries, too...  if multilib_for_best_abi was always
based on multilib_is_native_abi, then I expect it will be fine to
deprecate it.






-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlNn2LEACgkQ2ugaI38ACPDddAEAthcqIbx9/4TBM0rfqlDnXdk7
ZeFzOkHlUYv7xNGBoFMBALZItkBcJVO8VNQ1bvUYVf+j8W98JWmUt6MBgZdiZZm2
=a6pm
-END PGP SIGNATURE-