Revamped buildscript

[mfherbst]

This is a try at a cleaner buildscript and a cleaner Travis setup. All comments welcome.

Closes #84

[codecov]

Codecov Report

Merging #87 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #87   +/-   ##
=======================================
  Coverage   80.88%   80.88%           
=======================================
  Files          12       12           
  Lines        1245     1245           
=======================================
  Hits         1007     1007           
  Misses        238      238

Impacted Files	Coverage Δ
src/libfasttransforms.jl	89.32% <ø> (ø)	⬆️

---

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 f092c24...0b3cfe8. Read the comment docs.

[MikaelSlevinsky]

This seems to swap one dealbreaker for another: no sudo in the build.jl script, but now there are addons in the .travis.yml. Wouldn't this require every dependent package to do the same (for Travis testing)?

[mfherbst]

Yes, that's true ... but at least you don't have a problem when you are installing the code on a local laptop or cluster (given that the dependencies are there).

If you want to avoid any dependencies in downstream Travis, then you probably have to statically link all libraries into a final shared object and compile it with very general settings (i.e. no -march=native). This will, however, most likely have an impact on performance, so I'm not sure that's what you want.

Other than that you can of course only execute some installer code in the build.jl only if you are running in a Travis environment (Check the environment variable CI for true for example). I don't think this is clean, because it effectively hides the dependencies rather than making them explicit in the Travis script, but it would avoid running sudo code on Laptops and avoid tracking dependencies downstream.

Also it's likely that the Travis build environment changes from time to time and this way you force your users to always use the latest version of your package (with the up to date Travis code).

It's your call. I'm happy to implement that if you want.

[MikaelSlevinsky]

Do you know why the macOS builds are failing?

[mfherbst]

I have not yet invested the effort to find out. I expect I just missed to install some dependency or a small thing like that ...

I first wanted to wait whether you are still generally interested in the direction this PR is going and which of the options I presented in the previous comment would be the preferred 😄.

[dlfivefifty]

There are not too many packages dependent on FastTransforms.jl so if the easiest approach is that we need to change the Travis files for those, let's do it.

[mfherbst]

To clarify: What you want is to drop any special code for CI environments and install dependencies explicitly in the .travis.yml only, forcing downstream users to do the same?

[dlfivefifty]

Sure. I believe this will also help with Windows?

[mfherbst]

Could do ... I'm not a Windows person, so I'm not sure I can help much there, but I can give it a try.

[mfherbst]

Hooray, Travis is passing now on Mac and Linux. Not sure if I'll manage to fix Windows, so perhaps this should go in as is?

[dlfivefifty]

OK, but we still can't tag until Windows is fixed.

[MikaelSlevinsky]

I'll work on Windows. Should be straightforward if using an appveyor script for deps

[MikaelSlevinsky]

Thanks for taking a look at this, by the way! I'll merge to keep your contribution, but I have to make some modifications, because:

• building from source doesn't automatically identify the correct gcc (on Linux this would have been undetectable since you chose to use the system's gcc.)
• the line git checkout -b v$version (if the source directory already exists) errs and instead should be git checkout v$version.
• seems like git reset --hard might be overkill? Someone might try tinkering with the source (make)files to try to build on their system, but resetting hard I think would interfere with that.

Also, I just found out that if one builds from source then attempts to download the binaries, the julia download function can't overwrite the alias (but it can overwrite a lib!), so I'll switch ln -sf to mv -f.

[mfherbst]

Sure, that's completely fine.

git checkout -b v$version is definitely an error.

I did the git reset hard in order to make sure that if you change the required version of the C code upstream and I then do a pull, that for sure the correct version will be built and not silently an old version from me will be employed and subtle inconsistencies could result. Of course has the disadvantage you describe.

mv -f sounds better than ln from my taste.