Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Change USE flags when compiling with FEATURES=test

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


mattst88 at gentoo

Mar 17, 2012, 12:33 PM

Post #1 of 8 (495 views)
Permalink
Change USE flags when compiling with FEATURES=test

So you run set FEATURES=test to run a package's test suite during
keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
that package with USE=-test.

Can't we avoid this somehow? I presume in the vast majority of cases
emerging with FEATURES/USE=test doesn't actually affect what's
installed.

I'd guess we'd need to be able to remove 'test' from the set of IUSE
and have a new helper function to check if 'test' is in FEATURES?

Matt


ciaran.mccreesh at googlemail

Mar 17, 2012, 12:40 PM

Post #2 of 8 (487 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

On Sat, 17 Mar 2012 15:33:42 -0400
Matt Turner <mattst88 [at] gentoo> wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.
>
> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

If you want that, USE_EXPAND_IGNORE_CHANGES, like USE_EXPAND_HIDDEN,
would be cleaner. 'test' is already too special.

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


kentfredric at gmail

Mar 17, 2012, 12:43 PM

Post #3 of 8 (486 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

On 18 March 2012 08:33, Matt Turner <mattst88 [at] gentoo> wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.

Not so, there are a lot of things where USE="test" pulls in extra
dependencies, dev-perl/* is rife with them.

And I've seen some things where USE=test changes behaviour of the
compile phase sufficient that enabling USE=test *could* change the
code compiled as well.

But I think I see where you're comming from.

I just can't see a reasonable cover-all approach that wouldn't really
be a large nasty package-manager specific hack.

> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

And besides, I'll reinstall a package if so much as the MD5 changes
due to somebody adding keywording for an arch I don't use ;)

I think what would be more practical is a sane way to enable
FEATURES="" on a per-package level like USE flags in portage, then you
could enable FEATURES="test" for that one package and it would always
build that package with USE="test"

Paludis does this already via an extended use.conf syntax:

=dev-foo/bar-1.2 flag -otherflag BUILD_OPTIONS: optional_tests
LINGUAS: en

Perhaps portage does this already and I'm hiding under a rock, but I
haven't seen it, and I've just cheated the system with

linguas_en

and other similar manual USE_EXPAND tricks in my package.use

--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"


ryao at cs

Mar 17, 2012, 12:45 PM

Post #4 of 8 (488 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

On 03/17/12 15:43, Kent Fredric wrote:
> On 18 March 2012 08:33, Matt Turner <mattst88 [at] gentoo> wrote:
>> So you run set FEATURES=test to run a package's test suite during
>> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
>> that package with USE=-test.
>>
>> Can't we avoid this somehow? I presume in the vast majority of cases
>> emerging with FEATURES/USE=test doesn't actually affect what's
>> installed.
>
> Not so, there are a lot of things where USE="test" pulls in extra
> dependencies, dev-perl/* is rife with them.
>
> And I've seen some things where USE=test changes behaviour of the
> compile phase sufficient that enabling USE=test *could* change the
> code compiled as well.

To expand on this, I know that sys-devel/gcc will save a report of the
make check results to the filesystem when FEATURES=test is enabled.
Attachments: signature.asc (0.88 KB)


tetromino at gentoo

Mar 17, 2012, 12:51 PM

Post #5 of 8 (487 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

On Sat, 2012-03-17 at 15:33 -0400, Matt Turner wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.
>
> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

Typically "test" is added to IUSE only when building and/or running the
test suite requires specifying additional dependencies. So if we remove
"test" from IUSE, we would need to allow DEPEND to have FEATURES-based
conditionals. Which would probably mean a new EAPI.

I think the easier solution is to modify portage to ignore changes in
the "test" USE flag when doing "emerge --newuse".

-Alexandre.


zmedico at gentoo

Mar 17, 2012, 12:58 PM

Post #6 of 8 (486 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

On 03/17/2012 12:51 PM, Alexandre Rostovtsev wrote:
> I think the easier solution is to modify portage to ignore changes in
> the "test" USE flag when doing "emerge --newuse".

Yes, that's part of the plan [1] discussed in bug #373209.

[1] https://bugs.gentoo.org/show_bug.cgi?id=373209#c3
--
Thanks,
Zac


1i5t5.duncan at cox

Mar 18, 2012, 12:18 AM

Post #7 of 8 (478 views)
Permalink
Re: Change USE flags when compiling with FEATURES=test [In reply to]

Kent Fredric posted on Sun, 18 Mar 2012 08:43:55 +1300 as excerpted:

> I think what would be more practical is a sane way to enable FEATURES=""
> on a per-package level like USE flags in portage, then you could enable
> FEATURES="test" for that one package and it would always build that
> package with USE="test"
>
> Paludis does this already via an extended use.conf syntax:

> Perhaps portage does this already and I'm hiding under a rock, but I
> haven't seen it

What's you're definition of "sane"? Does it include the
/etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files
configuration options?

I've been using (and prefer) the latter for quite some time for various
per-package settings (tho not the particular one in question here)
without an issue. The former is newer but somewhat more limited, to
make.conf style direct variable assignments, while the latter allows full
bash flexibility, which I take advantage of.

For example, the following /etc/portage/env/media-video/smplayer-0.6.9-r1
allowed me to avoid editing the ebuild directly. (IIRC it was a patch
necessary to build the package with gcc-4.6. I'm on smplayer-0.7.1 now,
but the version-specific package-path limited deployment to just that one
version.)

post_src_prepare () {
sed -i '1i#define OF(x) x' src/findsubtitles/quazip/*.h
}


See the /etc/portage/package.env and /etc/portage/env/ sections of the
portage (5) manpage for the details.

So... Does that fit your definition of "sane"? =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman


zmedico at gentoo

Mar 18, 2012, 12:30 PM

Post #8 of 8 (474 views)
Permalink
Re: Re: Change USE flags when compiling with FEATURES=test [In reply to]

On 03/18/2012 12:18 AM, Duncan wrote:
> What's you're definition of "sane"? Does it include the
> /etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files
> configuration options?
>
> I've been using (and prefer) the latter for quite some time for various
> per-package settings (tho not the particular one in question here)
> without an issue. The former is newer but somewhat more limited, to
> make.conf style direct variable assignments, while the latter allows full
> bash flexibility, which I take advantage of.

For best results, you should use package.env for FEATURES settings,
because it's applied very early, so it will even take care of enabling
USE=test when resolving dependencies. On the other hand, bashrc settings
are applied much later, when the ebuild is being executed by bash. As a
general rule of thumb, use package.env for anything that involves
variable settings alone, and use bashrc for anything that must be
executed by bash.
--
Thanks,
Zac

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.