Closed p5pRT closed 7 years ago
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
I wanted the same exclusion capability for non-XS extensions so I created the attached patch. It allows both the -Dnoextensions=... and -Donlyextensions=... options in Configure to work for XS as well as non-XS extensions.
Using this patch\, I now exclude over 50 non-XS modules from my Perl builds. This gains me a 25% (5.12.x) to 35% (blead) reduction in the time needed to build\, test and install Perl. (In blead\, for example\, from 4 hrs. down to 2.5).
On Sun\, Nov 21\, 2010 at 03:19:21PM -0800\, Jerry D. Hedden wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Using this patch\, I now exclude over 50 non-XS modules from my Perl builds. This gains me a 25% (5.12.x) to 35% (blead) reduction in the time needed to build\, test and install Perl. (In blead\, for example\, from 4 hrs. down to 2.5).
Hi Jerry\,
As I mentioned on Thursday\, I'd prefer that we not end up with this functionality as something used by/for porters. Similarly\, the additional conditionalization of the test suite makes me somewhat uncomfortable for the same reasons.
Best\,
-Jesse
The RT System itself - Status changed from 'new' to 'open'
The consensus seems to be in favor of this patch. You're argument about conditionalizing the test suite is quite moot as that is the standard and not the exception. If excluding modules is not to be allowed\, then should we remove the -Dnoextensions=... and -Donlyextensions=... options to Configure? (That's a rhetorical question. The answer\, of course\, is 'Hell\, no'.)
The most fundamental philosophy of Perl it the capability to 'roll your own'\, and there is nothing in the current architecture that is sacrosanct to modification and flexibility.
Yes\, coding up tests correctly to account for modules not being present can be a pain\, but doing otherwise\, IMHO\, is a bug. I've dealt with that for years with the modules I've supported\, and I don't think it would be appropriate to reverse that mentality.
On Sun\, Nov 21\, 2010 at 19:21\, Jesse Vincent \jesse@​fsck\.com wrote:
On Sun\, Nov 21\, 2010 at 03:19:21PM -0800\, Jerry D. Hedden wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. Ā These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Using this patch\, I now exclude over 50 non-XS modules from my Perl builds. Ā This gains me a 25% (5.12.x) to 35% (blead) reduction in the time needed to build\, test and install Perl. Ā (In blead\, for example\, from 4 hrs. down to 2.5).
Hi Jerry\,
As I mentioned on Thursday\, I'd prefer that we not end up with this functionality as something used by/for porters. Ā Similarly\, the additional conditionalization of the test suite makes me somewhat uncomfortable for the same reasons.
Best\, -Jesse
On Sun\, 21 Nov 2010 19:55:48 -0500\, "Jerry D. Hedden" \jdhedden@​cpan\.org said:
> The consensus seems to be in favor of this patch. You're argument > about conditionalizing the test suite is quite moot as that is the standard > and not the exception. If excluding modules is not to be allowed\, then > should we remove the -Dnoextensions=... and -Donlyextensions=... > options to Configure? (That's a rhetorical question. The answer\, of > course\, is 'Hell\, no'.)
> The most fundamental philosophy of Perl it the capability to 'roll your > own'\, and there is nothing in the current architecture that is sacrosanct > to modification and flexibility.
> Yes\, coding up tests correctly to account for modules not being > present can be a pain\, but doing otherwise\, IMHO\, is a bug. I've dealt > with that for years with the modules I've supported\, and I don't think > it would be appropriate to reverse that mentality.
+1 # like @cpantesters: testers invent their personal testbed
-- andreas
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not-supported by the system/OS/architecture seems like a good reason to exclude the module from the start. If tests are well written\, they will be skipped anyway in the harness suite.
OTOH I don't think that excluding default modules from the CORE\, in whatever way\, should be supported in Configure for speeding up the build and tests. As Nicholas already mentioned.
I also see that these two statements have a conflicting overlap. It is up to the boss(es) to take a decision.
I wanted the same exclusion capability for non-XS extensions so I created the attached patch. It allows both the -Dnoextensions=... and -Donlyextensions=... options in Configure to work for XS as well as non-XS extensions.
Using this patch\, I now exclude over 50 non-XS modules from my Perl builds. This gains me a 25% (5.12.x) to 35% (blead) reduction in the time needed to build\, test and install Perl. (In blead\, for example\, from 4 hrs. down to 2.5).
There is another way to do this.
If you run Configure\, it will see if config.arch exists and run it if present: --8\<--- : configuration may be unconditionally patched via a 'config.arch' file if $test -f config.arch; then echo "I see a config.arch file\, loading it." >&4 . ./config.arch fi -->8---
So\, if you create one of your own\, and put it in the build folder just before you run Configure\, you can write a shell script (config.arch should be plain sh) that modifies $extensions to exclude the ones you do not want. YMMV
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20\, 11.00\, 11.11\, 11.23 and 11.31\, OpenSuSE 10.1\, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. Ā These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not-supported by the system/OS/architecture seems like a good reason to exclude the module from the start. If tests are well written\, they will be skipped anyway in the harness suite.
OTOH I don't think that excluding default modules from the CORE\, in whatever way\, should be supported in Configure for speeding up the build and tests. As Nicholas already mentioned.
I dont entirely agree. And we have precedent. When I was working on the regex engine it become extremely irritating to have to rebuild every extension so often.
I hacked the make file to make a minimal target which rebuilt the regex engine only\, with no other modules.
Its been in-core for years now.
I dont think its unreasonable to want to do this /in this way/.
That is\, i think it would be ok to have a
make homebrew mkae homebrew test
or something which did a reduced build cycle\, so long as the normal make/make test and configure behaviour stays the same.
And actually Jerry could use git rerere to set up alocal makefile patch that created such a target based on the make reonly and make test-reonly targets.
Yves
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. Ā These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not-supported by the system/OS/architecture seems like a good reason to exclude the module from the start. If tests are well written\, they will be skipped anyway in the harness suite.
OTOH I don't think that excluding default modules from the CORE\, in whatever way\, should be supported in Configure for speeding up the build and tests. As Nicholas already mentioned.
I dont entirely agree. And we have precedent. When I was working on the regex engine it become extremely irritating to have to rebuild every extension so often.
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
[...]
And actually Jerry could use git rerere to set up alocal makefile patch that created such a target based on the make reonly and make test-reonly targets.
Would you mind adding some tutorial-style docs for this approach to the bisecting sample in perlrepository.pod?
Cheers\, -Jan
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. Ā These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
Incidentally\, as H.Merijn has pointed out\, you can already do this with an override file. Simply assign the list of extensions you actually want in a file 'config.over' and Configure will automatically read it in at the very end. (Or\, you could put code in config.over to weed out the extensions you don't want.)
-- Andy Dougherty doughera@lafayette.edu
On Sun\, Nov 21\, 2010 at 07:55:48PM -0500\, Jerry D. Hedden wrote:
The consensus seems to be in favor of this patch. You're argument
What consensus? There was very little comment. I think that you're being premature in using the term.
Nicholas Clark
On Tue\, Nov 23\, 2010 at 11:07\, Nicholas Clark \nick@​ccl4\.org wrote:
On Sun\, Nov 21\, 2010 at 07:55:48PM -0500\, Jerry D. Hedden wrote:
The consensus seems to be in favor of this patch. Ā You're argument
What consensus? There was very little comment. I think that you're being premature in using the term.
Nicholas Clark
Agreed. It was premature. However\, there are some that are in favor.
On Tue Nov 23 07:36:50 2010\, doughera wrote:
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. ļæ½These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
Iām in favour of this patch\, as long as we donāt modify the test suite to accommodate broken builds.
--
Father Chrysostomos
On Fri Jan 06 23:46:45 2012\, sprout wrote:
On Tue Nov 23 07:36:50 2010\, doughera wrote:
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. ļæ½These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
Iām in favour of this patch\, as long as we donāt modify the test suite to accommodate broken builds.
A patch to permit exclusion of non-XS extensions was originally submitted by Jerry Hedden in Nov 2010. Jesse Vincent was skeptical. Others were more favorably inclined. Both Andy Dougherty and Father C. spoke in favor provided we don't spend time modifying the test suite to accommodate such an exclusion.
I suspect that if we were to adopt this patch\, the maintenance burden would fall on the Configure maintainers. I also suspect that the patch is old enough that it wouldn't apply cleanly\, though I haven't tested that.
Do we want to move forward with this?
Thank you very much. Jim Keenan
On Fri\, Sep 06\, 2013 at 07:12:46PM -0700\, James E Keenan via RT wrote:
On Fri Jan 06 23:46:45 2012\, sprout wrote:
On Tue Nov 23 07:36:50 2010\, doughera wrote:
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
I'm in favour of this patch\, as long as we don't modify the test suite to accommodate broken builds.
A patch to permit exclusion of non-XS extensions was originally submitted by Jerry Hedden in Nov 2010. Jesse Vincent was skeptical. Others were more favorably inclined. Both Andy Dougherty and Father C. spoke in favor provided we don't spend time modifying the test suite to accommodate such an exclusion.
I suspect that if we were to adopt this patch\, the maintenance burden would fall on the Configure maintainers. I also suspect that the patch is old enough that it wouldn't apply cleanly\, though I haven't tested that.
Do we want to move forward with this?
Yes\, I think that we should\, but specifically as sprout states\, that we don't modify the test suite to (attempt to) compensate for user-disabled modules.
I don't think that it will a significant ongoing burden on the Configure maintainers to have this functionality in place. (Once it is added).
It would be a long term cost if we start to feel the need to add skip()s in various test suites to ensure no tests failed for user-disabled modules\, because this has the potential to be a combinatorial explosion of permutations\, and a lot of manual work prone to errors.
Nicholas Clark
On Fri\, 13 Sep 2013 12:38:30 GMT\, nicholas wrote:
On Fri\, Sep 06\, 2013 at 07:12:46PM -0700\, James E Keenan via RT wrote:
On Fri Jan 06 23:46:45 2012\, sprout wrote:
On Tue Nov 23 07:36:50 2010\, doughera wrote:
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
I'm in favour of this patch\, as long as we don't modify the test suite to accommodate broken builds.
A patch to permit exclusion of non-XS extensions was originally submitted by Jerry Hedden in Nov 2010. Jesse Vincent was skeptical. Others were more favorably inclined. Both Andy Dougherty and Father C. spoke in favor provided we don't spend time modifying the test suite to accommodate such an exclusion.
I suspect that if we were to adopt this patch\, the maintenance burden would fall on the Configure maintainers. I also suspect that the patch is old enough that it wouldn't apply cleanly\, though I haven't tested that.
Do we want to move forward with this?
Yes\, I think that we should\, but specifically as sprout states\, that we don't modify the test suite to (attempt to) compensate for user- disabled modules.
I don't think that it will a significant ongoing burden on the Configure maintainers to have this functionality in place. (Once it is added).
It would be a long term cost if we start to feel the need to add skip()s in various test suites to ensure no tests failed for user-disabled modules\, because this has the potential to be a combinatorial explosion of permutations\, and a lot of manual work prone to errors.
Nicholas Clark
Jerry (original poster):
Would you like to draw a new version of this patch against blead and re-submit it?
That would give us something to consider after 5.26.0 is released.
(Otherwise\, the ticket is so old that it should be closed.)
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
I no longer involve myself with building custom versions of perl as I did in the past\, so I'm afraid I can't easily generate an updated version of this patch. Yes\, you should probably just close the ticket. Thanks.
On Sun\, Feb 26\, 2017 at 6:46 PM\, James E Keenan via RT \< perlbug-followup@perl.org> wrote:
On Fri\, 13 Sep 2013 12:38:30 GMT\, nicholas wrote:
On Fri\, Sep 06\, 2013 at 07:12:46PM -0700\, James E Keenan via RT wrote:
On Fri Jan 06 23:46:45 2012\, sprout wrote:
On Tue Nov 23 07:36:50 2010\, doughera wrote:
On Mon\, 22 Nov 2010\, Jan Dubois wrote:
On Mon\, 22 Nov 2010\, demerphq wrote:
On 22 November 2010 09:01\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote:
On Sun\, 21 Nov 2010 15:19:21 -0800\, "Jerry D. Hedden" (via RT) \perlbug\-followup@​perl\.org wrote:
In order to save time building and testing Perl\, I use the -Dnoextensions=... option in Configure to exclude over a dozen XS extensions when building Perl. These include extensions I don't need (e.g.\, Sys/Syslog)\, don't want (e.g.\, Text/Soundex) or that aren't supported on my current architecture (e.g.\, IPC/SysV).
Not building all the extensions also helps with bisecting (even though a Configure based mechanism alone won't help on Windows\, which needs help the most).
On balance\, I'm in favor of this extension to an existing command-line option. For a variety of reasons\, there are times when you definitely want Configure to hand you more rope.
Equally emphatically\, however\, I don't think any compensating changes to the test suite are appropriate at this time. If I deliberately exclude an extension that "we" expect to be there\, then I must live with the consequences. If I go out of my way to build a broken perl\, I expect the test suite to fail.
I'm in favour of this patch\, as long as we don't modify the test suite to accommodate broken builds.
A patch to permit exclusion of non-XS extensions was originally submitted by Jerry Hedden in Nov 2010. Jesse Vincent was skeptical. Others were more favorably inclined. Both Andy Dougherty and Father C. spoke in favor provided we don't spend time modifying the test suite to accommodate such an exclusion.
I suspect that if we were to adopt this patch\, the maintenance burden would fall on the Configure maintainers. I also suspect that the patch is old enough that it wouldn't apply cleanly\, though I haven't tested that.
Do we want to move forward with this?
Yes\, I think that we should\, but specifically as sprout states\, that we don't modify the test suite to (attempt to) compensate for user- disabled modules.
I don't think that it will a significant ongoing burden on the Configure maintainers to have this functionality in place. (Once it is added).
It would be a long term cost if we start to feel the need to add skip()s in various test suites to ensure no tests failed for user-disabled modules\, because this has the potential to be a combinatorial explosion of permutations\, and a lot of manual work prone to errors.
Nicholas Clark
Jerry (original poster):
Would you like to draw a new version of this patch against blead and re-submit it?
That would give us something to consider after 5.26.0 is released.
(Otherwise\, the ticket is so old that it should be closed.)
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
On Tue\, 28 Feb 2017 02:50:47 GMT\, jdhedden@cpan.org wrote:
I no longer involve myself with building custom versions of perl as I did in the past\, so I'm afraid I can't easily generate an updated version of this patch. Yes\, you should probably just close the ticket. Thanks.
Accordingly\, closing. Thanks for getting back to us on this.
-- James E Keenan (jkeenan@cpan.org)
@jkeenan - Status changed from 'open' to 'rejected'
Migrated from rt.perl.org#79538 (status was 'rejected')
Searchable as RT79538$