Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Update SymEngine and fix build issues #40

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

Closed
wants to merge 4 commits into from

Conversation

isuruf
Copy link
Member

@isuruf isuruf commented Jan 27, 2016

  • Remove running of tests in main repo's script

@isuruf
Copy link
Member Author

isuruf commented Jan 27, 2016

Depends on symengine/symengine#782

@certik
Copy link
Contributor

certik commented Jan 27, 2016

The changes look good, +1 if tests pass. You should probably update the hash to the latest master.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

All tests pass, except the Sage ones, that it can't find GMP.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

I think we need to set -DCMAKE_PREFIX_PATH in setup.py to point to $SAGE_LOCAL, then it should find it. Do you know a best place to do this in the setup.py? We should just add it on a command line to setup.py only when Sage is used.

Any ideas how it was finding GMP before?

@isuruf
Copy link
Member Author

isuruf commented Jan 28, 2016

@certik, sage issue is because of the new sage archive's naming extracted folder name is different. It's SageMath now. I fixed this in another branch, but there seems to be a problem with sage's gcc. Let me get back to you after checking

@certik
Copy link
Contributor

certik commented Jan 28, 2016

I think they use gcc 4.9.2 or so. If there are any compilation issues, then we need to fix them.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

But why cannot we use the old version of Sage for this PR that worked? We can port to new Sage in a new PR.

@isuruf
Copy link
Member Author

isuruf commented Jan 28, 2016

Old sage version are not available anymore in the link. Maybe they are archived somewhere

@certik
Copy link
Contributor

certik commented Jan 28, 2016

I can't find it either. That's terrible.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

How is it that this line

- source bin/install_travis.sh
didn't fail the build when the script exited with an error?

@certik
Copy link
Contributor

certik commented Jan 28, 2016

We should probably call it without the source.

@isuruf
Copy link
Member Author

isuruf commented Jan 28, 2016

Because set -e isn't added to the top of install_travis.sh. source has to be used because the script is setting up the environment.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

I tried to fix it in #41, but I think there is an issue with setting set -e and sourcing it, because then it propagates into the parent shell and actually makes Travis fail. So the right solution is to install things as a regular script with set -e. And then just have a tiny script that sets up environment (without set -e), and that one will be sourced.

Because when installation fails, we should simply fail immediately.

@isuruf
Copy link
Member Author

isuruf commented Jan 28, 2016

You can also do set +e at the end

@certik
Copy link
Contributor

certik commented Jan 28, 2016

Except when it fails, then set +e will never be executed. But then I guess it will fail anyway, so maybe that's ok.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

Set LD_LIBRARY_PATH to $SAGE_LOCAL. That should fix it.

@certik
Copy link
Contributor

certik commented Jan 28, 2016

@isuruf let's get the Sage stuff out of this PR, and merge #42 which restores the old Sage version and all tests pass there. In this PR let's just update the SymEngine and make sure everything passes.

We can then update Sage in a new PR.

@certik
Copy link
Contributor

certik commented Jan 29, 2016

I like the changes up to 95d4aa0, did anything fail at this point (I am testing it in #43)? Let's fiddle with Travis in another PR, as we talked, we have to be a bit more careful here.

@certik
Copy link
Contributor

certik commented Feb 1, 2016

Closing in favor of #45.

@certik certik closed this Feb 1, 2016
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.

2 participants