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

Unify #71

Merged
merged 12 commits into from
Jan 19, 2018
Merged

Unify #71

merged 12 commits into from
Jan 19, 2018

Conversation

casperdcl
Copy link
Member

@casperdcl casperdcl commented Dec 11, 2017

continued from #69:

closes SyneRBI/SIRF-SuperBuild#39

Ambitious

  • useSIRF-SuperBuild/docker/*.sh scripts
    • SIRF/.travis.yml
    • SIRF-SuperBuild/.travis.yml
    • VM

@codecov
Copy link

codecov bot commented Dec 11, 2017

Codecov Report

Merging #71 into master will increase coverage by 1.65%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   55.51%   57.17%   +1.65%     
==========================================
  Files           2        2              
  Lines        1632     1548      -84     
==========================================
- Hits          906      885      -21     
+ Misses        726      663      -63
Impacted Files Coverage Δ
src/xGadgetron/pGadgetron/pGadgetron.py 49.87% <0%> (+0.17%) ⬆️
src/xSTIR/pSTIR/pSTIR.py 65.64% <0%> (+4%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 950078c...c25c73c. Read the comment docs.

@casperdcl
Copy link
Member Author

casperdcl commented Dec 12, 2017

yay it builds -.-

@casperdcl
Copy link
Member Author

casperdcl commented Dec 12, 2017

ok sarcasm aside, that ccache really helps. under 4min per job, most of which is not compiling.

@casperdcl casperdcl added this to the v1.0.0 milestone Dec 12, 2017
@casperdcl
Copy link
Member Author

@KrisThielemans
Copy link
Member

great about ccache, I tried to do this in the CMake-recommended way SyneRBI/SIRF-SuperBuild#58 but this didn't seem to help. not sure why. I haven't tested that PR outside of Travis. comments welcome there.

@KrisThielemans
Copy link
Member

Before you do lots more work on the actual "unification" can we discuss the plan? I'm not sure how it fits with what we had in mind for the VM, docker etc. Probably no time on Friday. next tcon?

@SyneRBI SyneRBI deleted a comment from coveralls Dec 13, 2017
@SyneRBI SyneRBI deleted a comment from coveralls Dec 13, 2017
@SyneRBI SyneRBI deleted a comment from coveralls Dec 13, 2017
@SyneRBI SyneRBI deleted a comment from coveralls Dec 13, 2017
@SyneRBI SyneRBI deleted a comment from coveralls Dec 13, 2017
@SyneRBI SyneRBI deleted a comment from codecov bot Dec 13, 2017
@casperdcl
Copy link
Member Author

casperdcl commented Dec 13, 2017

@KrisThielemans turns out it was just travis lying, still 20min/build. Odd, since I get a much quicker build when I use ccache locally. It might be because of language as you said. travis-ci/travis-ci#4090

regarding python/pip (esp. on Mac): travis-ci/travis-ci#2312, pypa/pip#3813, pypa/pip#1668

@KrisThielemans
Copy link
Member

sounds like another python version mixup.

@casperdcl
Copy link
Member Author

still failing on mac though, even with tests using ${PYTHON_EXECUTABLE}

@KrisThielemans
Copy link
Member

yes. In the log we see the conflict:

-- Found PythonInterp: /usr/local/bin/python2 (found suitable version "2.7.14", minimum required is "2") 
-- Found PYTHON_EXECUTABLE=/usr/local/bin/python2
-- Python version 2.7.14
-- Found PythonLibs: /System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib (found suitable version "2.7.10", minimum required is "2") 

we currently use

-DPYTHON_LIBRARY=$(python-config --prefix)/lib/libpython2.7.dylib -DPYTHON_INCLUDE_DIR=$(python-config --prefix)/include/python2.7"

but that isn't good (enough). According to the CMake doc, we need to do

find_package(PythonInterp)
find_package(PythonLibs)

which we do here. But then overriding the above variables is probably confusing. Might be better to override PYTHON_EXECUTABLE.

@casperdcl
Copy link
Member Author

ah yes, but why do we override this on osx in the first place? can we not just rely on find_package like we do with linux?

@KrisThielemans
Copy link
Member

the internet is full of reports by people struggling with CMake and Python on OSX. We got it to work with that particular combination, but that was because we didn't test the python executables from within CMake (and were (un)lucky to pick up the matching python when running the test from the script).

Possibly @bathomas and @rijobro can comment. They recently struggled quite a lot as well.

@casperdcl
Copy link
Member Author

computer problems

- libfftw3-dev
- python-dev
- python3-dev
- python-tk
Copy link
Member

Choose a reason for hiding this comment

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

why include this? We don't need it as far as I know

Copy link
Member Author

Choose a reason for hiding this comment

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

we definitely need -dev and -tk, arguably not for both python and python3 (depending on the build matrix) but

  1. it's neater to put both here rather than require sudo to apt-get the appropriate version
  2. it's a quick download/install
  3. it doesn't affect osx

What about the other dependencies, such as root-system-bin? Are they really all required? I just copied from the SuperBuild.

Copy link
Member

Choose a reason for hiding this comment

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

agree to install both python2 and 3 here. still mystified about -tk as I've never had to install this before (maybe it was there).

yes, get rid of root-system-bin. Could be used to enable ROOT support for STIR, but then it'd need other packages as well (and is sure to let to other compilation problems, so we won't do this now).

Copy link
Member Author

Choose a reason for hiding this comment

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

ok, building without root-system-bin now. python-tk is needed (https://travis-ci.org/CCPPETMR/SIRF/jobs/315938695) and would have been installed back when we had language: python. We need language: cpp now in order to get ccache to work (which is evidently much more important than caching pip)

let me know if you think anything else can be removed. it's about 1:30min to apt-get things at the moment.

- popd
# get pip
- curl -0 https://bootstrap.pypa.io/get-pip.py -o get-pip.py
- python$PYMVER get-pip.py --user
Copy link
Member

Choose a reason for hiding this comment

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

no guarantee that this python will be the one found by cmake. would have to enforce it in the cmake call by setting PYTHON_EXECUTABLE. For STIR, I did it the other way round: first run CMake, then use whatever python it found.

Copy link
Member Author

@casperdcl casperdcl Dec 19, 2017

Choose a reason for hiding this comment

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

just tried (https://travis-ci.org/CCPPETMR/SIRF/builds/318679147), but it's going to fail (osx) since the libs and executable versions are still mismatched, don't want to look into getting them to match (2.7.10 bin, 2.7.14 lib) - anyone else have any ideas?


@author: Evgueni Ovtchinnikov
{licence}
Copy link
Member

Choose a reason for hiding this comment

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

this is clearly cleaner. However, it means the license info isn't actually inside the file. I don't think this is according to Apache 2 instructions (and it assumes the file will not be distributed on its own).
Not very important for these tests of course, but I think best to keep as-was (feel free to argue!)

Copy link
Member Author

Choose a reason for hiding this comment

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

  1. lawyers need to talk to programmers more to understand that "requiring" paragraphs of licence text per-file is insane, irrespective of standaloneness
  2. making "reasonable efforts" per-file (such as this new version) is legally sufficient, regardless of whether that contradicts what any licence text says
  3. this file does actually need and contain the licence text via the import. Running pydoc/help() on this would show the full licence text
  4. because of the above dependency, this file could not work standalone without deliberate modification to remove any reference to licence, which would be clearly illegal
  5. "requiring" paragraphs of licence text per-file is insane
  6. see above
  7. decent programmers do not do avoidable duplication. decent lawyers do not do avoidable repetition. codacy doesn't like code duplication. Even as it stands, this PR fixes some, but not all the duplication
  8. see 1, 5 and 6

Happy to hear any counter arguments!

Copy link
Member

Choose a reason for hiding this comment

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

:-) seems you have strong opinions! I'm ok with this in these test files only. nowhere else though. sorry.

Copy link
Member Author

Choose a reason for hiding this comment

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

groan

.travis.yml Outdated
@@ -125,6 +127,10 @@ before_install:
pushd $HOME/Library/Python/$PYMVER*/bin
export PATH="$PWD:$PATH"
popd
# fix CMake variables
export BUILD_FLAGS="$BUILD_FLAGS -DPYTHON_LIBRARY=$(python-config --prefix)/lib/libpython2.7.dylib"
Copy link
Member

Choose a reason for hiding this comment

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

what happens if you just don't set PYTHON_LIBRARY etc, only PYTHON_EXECUTABLE?

@KrisThielemans
Copy link
Member

regarding dependencies, could list only relevant boost packages (they are in the External_boost*), but I think we have better things to do in life.

@casperdcl casperdcl merged commit c25c73c into master Jan 19, 2018
@casperdcl casperdcl mentioned this pull request Jan 19, 2018
@casperdcl casperdcl deleted the unify branch January 19, 2018 17:51
johannesmayer pushed a commit to johannesmayer/SIRF that referenced this pull request Feb 21, 2022
- remove all KEM recon until the end
- make neighbourhood=3 in all the cells except where we need to change it
- remove repetition of reconstruction: reuse image reconstructed in previous cell
- use 21 subsets and 2 full iterations
johannesmayer pushed a commit to johannesmayer/SIRF that referenced this pull request Feb 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Running Travis on SIRF branch or PRs Test Updates
2 participants