improve travis and appveyor builds

[vb216]

Appveyor build changed to split out some package config into a bash file, gives more flexibility around logic for what packages to install so we can save time and improve reliability there. Looks to build the whole lot OK now. Also more readable, text it platform then project so you can see on the main screen what's going on.

Travis build updated to the point where I think everything builds apart from mxnet. I guess that might be the risk of building against a master repo point rather than a release, you can catch upstream bugs/impacts on yours (I'm guessing thats the issue rather than build config but I don't know for sure).

CUDA problem fixed by separating out the download rather than using brew.

I'm seeing occasional failures due to downloads, wonder if they have intermittent connection issues. Down the road, could put some retry logic, but easy enough just to hit the 'rebuild' button if you see a connection issue in the log.

[saudet]

We shouldn't need a copy here since the presets look in the default installation directory.

[saudet]

Looks good! Thanks! Apart from my comments inline, setupPackages.sh, maybe install-windows.sh would be better for self-documentation?

Yeah, I'll need to figure out how to pick up some "releases" for MXNet. It's not entirely clear what their system is. But we're going to hit limits building all of that + Caffe. I'm currently working on the loader and builder in JavaCPP so that we can have it install and load everything--including header files--in .m2/repository, as explained at bytedeco/javacpp#43 . This way, as long as we specify that directory in the cache, and list projects after their dependencies, it should work automagically. Getting Maven to cooperate with all that is a bit challenging, but I should get it working, soonish. :)

[vb216]

Pretty much all in apart from the hdf5 part - from what I've tested there needs to be either a cp or mv, because the install puts it in a Program Files (x86) as its installing on a win64 build server. From a few tests, I seem to get issues if I try mv but not cp (maybe something else during the build looks back to the x86 dir from a path or something?). So seemed easiest to go with that

[saudet]

I mean, the presets for HDF5 when building for windows-x86 are going to look into
"C:/Program Files (x86)/HDF_Group/HDF5/1.10.0/". If they are not, then it's a bug:
https://github.com/bytedeco/javacpp-presets/blob/master/hdf5/src/main/java/org/bytedeco/javacpp/presets/hdf5.java#L49

[vb216]

Strange.. that suggests to me its a bug.. (I assumed on a native win32 setup, maybe Program Files becomes the 32bit program files or something like that). Will double check..

…

On 24 April 2017 at 12:47, Samuel Audet ***@***.***> wrote: I mean, the presets for HDF5 when building for windows-x86 are going to look into "C:/Program Files (x86)/HDF_Group/HDF5/1.10.0/". If they are not, then it's a bug: https://github.com/bytedeco/javacpp-presets/blob/master/ hdf5/src/main/java/org/bytedeco/javacpp/presets/hdf5.java#L49 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#410 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMYRJxIAMCXvlcLcEsGYydkp7MzM9oKTks5rzIvigaJpZM4NDhVg> .