Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add '-Dusethreads' to perl build Configure #6

Merged
merged 14 commits into from
Dec 7, 2016

Conversation

tomkinsc
Copy link
Contributor

@tomkinsc tomkinsc commented Sep 6, 2016

Closes #5
Fixes #4 ?

The synchronization overhead of perl with threading support is minimal. Single-threaded perl programs will not see a significant performance penalty from being run on perl supporting threads (at most about 5%), however without threading support, multi-threaded programs cannot run.
It would be a sane default to include ‘-Dusethreads’ in the perl build script, so any packages that depend on ‘perl’ will run, whether they are single- or multi-threaded. It may make sense to add a second feedstock for something like ‘perl-singlethreaded’ for those who need the absolute best efficiency for their single-threaded perl applications.

This includes the flag ordering change present in #5 where -de is added at the end, since apparently the order matters.

Edit by @jakirkham : Added closes/fixes lines above.

The synchronization overhead of perl with threading support is minimal.
Single-threaded perl programs will not see a significant performance
penalty from being run on perl supporting threads (at most about 5%),
however without threading support, multi-threaded programs cannot run.
It would be a sane default to include ‘-Dusethreads’ in the perl build
script, so any packages that depend on ‘perl’ will run, whether they
are single- or multi-threaded. It may make sense to add a second
feedstock for something like ‘perl-singlethreaded’ for those who need
the absolute best efficiency for their single-threaded perl
applications.
@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@tomkinsc tomkinsc mentioned this pull request Sep 6, 2016
4 tasks
@@ -1,5 +1,5 @@
#!/bin/bash
sh Configure -de -Dprefix=$PREFIX -Duserelocatableinc
sh Configure -Dusethreads -Duserelocatableinc -Dprefix=$PREFIX -de
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I believe there was something special about how these needed to be ordered. See issue ( #4 ). If you could explain a bit why this order is better, that would be very helpful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also please see PR ( #5 ) where I was trying to do the same thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I placed -de at the end for that reason (saw your pull request).

@tomkinsc
Copy link
Contributor Author

tomkinsc commented Sep 6, 2016

It looks like the build failed with errors such as this one:

Running Makefile.PL in cpan/Pod-Checker ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.a WARNING: Setting ABSTRACT via file 'lib/Pod/Checker.pm' failed

Any ideas how to correct it?

@tomkinsc tomkinsc closed this Sep 8, 2016
@tomkinsc tomkinsc reopened this Sep 8, 2016
@bgruening
Copy link
Contributor

@tomkinsc no idea from my side :(

@bgruening
Copy link
Contributor

@tomkinsc maybe the trick mentioned at the end of the error report helps?

### You may have to set your dynamic library search path,
### LD_LIBRARY_PATH, to point to the build directory:
###   setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness
###   LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness
###   export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness
### for csh-style shells, like tcsh; or for traditional/modern
### Bourne-style shells, like bash, ksh, and zsh, respectively.

@bgruening
Copy link
Contributor

Moreover, this Insecure directory in $ENV{PATH} while running with -T switch at ../../t/test.pl line 738. seems to indicate that a few files and folders are world-writable, which is not allowed.

@jakirkham
Copy link
Member

If there are few Bioconda people interested in helping maintain Perl, that would be great. I think you guys use Perl more often than I or others do. So you probably have a better idea of how best to get it to work.

@bgruening
Copy link
Contributor

@jakirkham we are here to help :)
@tomkinsc are the travis changes really needed?

@bgruening
Copy link
Contributor

@tomkinsc I cancelled the previous builds so that the last one is faster :)

@tomkinsc
Copy link
Contributor Author

@bgruening: Yes, the changes were needed since I had to update the CircleCI-related files, and Travis had a shared dependency. Thanks for cancelling the previous builds! :)

@tomkinsc
Copy link
Contributor Author

Not sure about the AppVeyor failure.

@bgruening
Copy link
Contributor

It seems that the appveyor config also needs some updates? Other feedstocks have a different config.
@jakirkham I thought conda-smithy is updating these configs, no?

@jakirkham
Copy link
Member

So we have a webservice that re-renders a random subset of feedstocks daily. However, the number of feedstocks has really grown and that approach is proving itself insufficient for this scale. We have been discussing an asynchronous webservice that PRs re-renderings against feedstocks/PRs when they get updated. ( conda-forge/conda-forge-webservices#74 ) That should do a better job going forward.

In the near term, I have put a fair bit of effort into just making conda-smithy easier to use and documenting it better in the hopes that people can do this themselves as needed.

@bgruening
Copy link
Contributor

@jakirkham I guess this is fair enough. We should just know that smithy is not taking care of it :)

@jakirkham
Copy link
Member

Also the Windows build didn't/doesn't actually build Perl. Instead it installed a pre-built binary of Perl. This is what @msarahan found to work at the time. Hence why it didn't/shouldn't have a Python matrix on AppVeyor.

@bgruening
Copy link
Contributor

So skip: True # [win] is the way forward? Good to know.

@jakirkham
Copy link
Member

jakirkham commented Nov 14, 2016

Uh, sorry, I think the wires got crossed. What I mean is there is a Windows build, but it just copies StrawberryPerl over into the conda build prefix. We just don't need the typical python build dependency or vc features.

@tomkinsc
Copy link
Contributor Author

I don't have time to address this, so I'm closing this PR; feel free to fork my branch. Setting up various tokens and "re-rendering" the automation infrastructure is a silly amount of overhead when I simply wanted to add a flag to the conda build script.

@tomkinsc tomkinsc reopened this Nov 15, 2016
@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@tomkinsc
Copy link
Contributor Author

Thanks for re-rendering the feedstock. I've merged the updated master into this branch.

@jakirkham
Copy link
Member

Of course, glad to help.

It seems there are some subtle differences on some of the CI files. Could you please click the Allow edits from maintainers box and I can push a fix to clean those up directly to your PR?

@tomkinsc
Copy link
Contributor Author

Done.

@jakirkham
Copy link
Member

Thanks.

old_ld_library_path="$LD_LIBRARY_PATH"
fi

export LD_LIBRARY_PATH=$(pwd)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please explain why this change was needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested by prior perl test failures.

export LD_LIBRARY_PATH=$(pwd)

# world-writable files are not allowed
chmod -R o-w $SRC_DIR
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also would be good to get a bit more knowledge on why the permissions are off.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incorrect as built by perl?

sh Configure -de -Dprefix=$PREFIX -Duserelocatableinc
make

# change permissions again after building
chmod -R o-w $SRC_DIR
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and how they become wrong again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Built files may have incorrect permissions, so the script corrects before building and again after. Tests were previously failing because various files were world-writable.


# world-writable files are not allowed
chmod -R o-w $SRC_DIR

sh Configure -de -Dprefix=$PREFIX -Duserelocatableinc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we still planning to add -Dusethreads?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how it was lost in this PR, but yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I guess this is needed before we can ask for a merge :)


if [ ! -z "$old_ld_library_path" ]; then
export LD_LIBRARY_PATH="$old_ld_library_path"
fi
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to set it back? Doesn't conda-build override this anyways?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If conda-build will restore it, then this can be removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this can be removed.

Copy link
Contributor

@bgruening bgruening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess with these two changes we can ask for merging it.
Thanks @tomkinsc.


# world-writable files are not allowed
chmod -R o-w $SRC_DIR

sh Configure -de -Dprefix=$PREFIX -Duserelocatableinc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I guess this is needed before we can ask for a merge :)


if [ ! -z "$old_ld_library_path" ]; then
export LD_LIBRARY_PATH="$old_ld_library_path"
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this can be removed.

@bgruening
Copy link
Contributor

@tomkinsc do you have time to finishe this one?

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@bgruening
Copy link
Contributor

@jakirkham ready to be merged? :)
Thanks a lot @tomkinsc!

@jjhelmus
Copy link
Contributor

jjhelmus commented Dec 4, 2016

Any idea if these changes would make perl relocatable (ie fix #4)? I've been trying to re-build the conda-forge autoconf package with conda-build 2.x and something with the current perl build is causing issues.

I'll move this topic to it's own issue this is unrelated to the current changes.

@jjhelmus
Copy link
Contributor

jjhelmus commented Dec 4, 2016

Please ignore my last comment. The failure I was seeing is unrelated to the perl package. Sorry for any confusion.

@tomkinsc
Copy link
Contributor Author

tomkinsc commented Dec 4, 2016

Ready to merge!

make test
make install
make install
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: Fixed to a terminal EOF again.

@jakirkham jakirkham merged commit b957735 into conda-forge:master Dec 7, 2016
@tomkinsc tomkinsc deleted the ct-perl-theaded-by-default branch December 8, 2016 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

perl conda package is not relocatable
5 participants