Bug 477944 – gnome2-multilib.eclass: add an eclass for native multilib support

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Pacho Ramos 2013-07-23 20:24:30 UTC]

Some libs are using gnome2.eclass for building, the idea would be to have something like cmake-multilib.eclass:
EXPORT_FUNCTIONS src_configure src_compile src_test src_install

gnome2-multilib_src_configure() {
        multilib_parallel_foreach_abi gnome2_src_configure "${@}"
}

gnome2-multilib_src_compile() {
        multilib_foreach_abi gnome2_src_compile "${@}"
}

gnome2-multilib_src_test() {
        multilib_foreach_abi default "${@}"
}

gnome2-multilib_src_install() {
        gnome2-multilib_secure_install() {
                gnome2_src_install "${@}"

                # Make sure all headers are the same for each ABI.
                multilib_check_headers
        }

        multilib_foreach_abi gnome2-multilib_secure_install "${@}"
}

[Comment 1 Alexandre Rostovtsev (RETIRED) 2013-07-23 20:33:08 UTC]

Can we fold this into gnome3.eclass with PATCHES support etc.?

[Comment 2 Pacho Ramos 2013-07-23 20:50:04 UTC]

I wouldn't block this by gnome3.eclass effort (it will include much more changes, like also the GCONF_DEBUG stuff, using autotools-utils.eclass if possible, drop G2CONF...), while this one is much more simple

We can commit this and, once we have a gnome3.eclass, let it also be multilib happy. Otherwise, we will probably end delaying so too much (as usually occurs in long standing eclass issues :S)

[Comment 3 Gilles Dartiguelongue (RETIRED) 2013-07-31 21:54:26 UTC]

Guys, if you are willing to write a new eclass, just go ahead and have it reviewed. I'm more inclined to have our current one evolve. It is a slow path because we need to be considerate about the impact of each changes but this is the way for all eclasses the day they are commited to the tree.

So please, if you have ideas, I'd rather you file a bug report with a clearly written grief against current eclass, what behavior your would like to see to fix it and move on from there.

The major obstacle until now to all non-trivial changes as always been the "get together to have a clear picture and decide something".

Having a gnome3.eclass is going to send the wrong signal imho, things haven't changed as much as the name would say.

[Comment 4 Pacho Ramos 2013-07-31 21:58:07 UTC]

Then, better discuss it in a different bug... maybe we need to review the old eclass tracker

[Comment 5 Pacho Ramos 2013-08-08 06:37:48 UTC]

Could anyone review the eclass commented in comment#0? Thanks (I guess we would need to send it to gentoo-dev ML too)

[Comment 6 Michał Górny 2013-08-08 07:49:16 UTC]

@Pacho, please consider using multilib-minimal since that people will most likely use to override the phases. I'm probably going to transform autotools-multilib as a wrapped to that as well.

[Comment 7 Pacho Ramos 2013-08-15 07:03:51 UTC]

@Michal, I guess it should go similar to netsurf.eclass then... but I don't fully understand the advantage of adding another layer (multilib-minimal) here :/

[Comment 8 Michał Górny 2013-08-15 11:35:47 UTC]

(In reply to Pacho Ramos from comment #7)
> @Michal, I guess it should go similar to netsurf.eclass then... but I don't
> fully understand the advantage of adding another layer (multilib-minimal)
> here :/

Say, you want to add another thing to be done in multilib_src_compile(). It's a bit about:

src_compile() {
  gnome2-multilib_src_compile

  func() {
    ...
  }
  multilib_foreach_abi func
}

or:

src_compile() {
  func() {
    gnome2_src_compile
    ...
  }
  multilib_foreach_abi func
}

vs:

multilib_src_compile() {
  gnome2_src_compile

  ...
}

I hit similar issues when converting stuff to autotools-multilib.

[Comment 9 Pacho Ramos 2013-08-15 19:24:48 UTC]

Ah, ok :)

[Comment 10 Michał Górny 2014-03-01 22:20:59 UTC]

I'm honestly not convinced that we want this. I'd just do multilib-minimal w/ proper gnome function calls...

[Comment 11 Pacho Ramos 2014-10-02 10:40:05 UTC]

(In reply to Michał Górny from comment #10)
> I'm honestly not convinced that we want this. I'd just do multilib-minimal
> w/ proper gnome function calls...

Looks like that is the way that was followed and, well, doesn't look so bad to me as I thought before. Sorry for the noise ;)