Closed elliotwoods closed 9 years ago
To break out the scripts a bit:
Same for the Addons:
[trimmed by @elliotwoods to ones which have libs]
$ ./apothecary -t vs download core addons
Downloading "FreeImage"
... skipping, src dir already exists
Downloading "android_configure"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 416 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 385 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2762k 100 2762k 0 0 35440 0 0:01:19 0:01:19 --:--:-- 41837
It looks like downloading failed for "android_configure"
Seems like can't just download all right? will start going through them
is there a reason not to upgrade to glew 1.12? it also builds fine though I think apothecary builds it as Win32
still trying to spend some time on this today but haven't been able to so far.
let's stick to same versions as osx / other platforms. if they're on 1.12 then let's use that also
I think they are still on 1.11 though don't quote me on that
for GLEW the script needs to change to
vs-build "glew_static.vcxproj" Build "Release|x64"
but apothecary also doesn't handle architecture switching for compiling with VS so in apothecary line 789 needs to change to:
cmd.exe /c 'call "%VS'${VS_VER}'0COMNTOOLS%vsvars32.bat" && '$VS_BUILD_TOOL' '$1' /'${2:-Build}' "'${3:-Release}'"'
Also updating VS_VER to 14 on line 79
How do we want to handle the libraries because GLEW has it build as glew32s even if its x64. Should we put it in folders (eg /win32 and /x64) or rename the files like the osx version
agreed - libs should be the same versions as in the scripts. for addons the only ones that matter are OpenCV and ofxAssimpModelLoader as there the only ones with static libs.
@elliotwoods the download core addons also didn't work for me. I ended up doing each one individually.
eg: ./apothecary -t vs download FreeImage
I think POCO should be the most problematic. It currently doesn't have any VS2015 project to build, and its CMake structure is bugged (as I remember). (See a short discussion about CMake implementation with the major POCO contributor, very old but seems to remain relevant: https://github.com/pocoproject/poco/commit/4297d78621d8192339bf78d0e6b5dde189141063#commitcomment-4800811 /!\ big commit)
Ping @stammen and @MSOpenTech from https://github.com/MSOpenTech/openFrameworks/issues/21. Maybe some advice for libraries' compilations?
in light of the poco information, please keep any work on this separate from the master branch until complete, so that we don't end up with any half-finished but broken components which could delay 0.9.0 even more.
What command line programs do you guys use? I am using git for windows and am getting an error with cairo where the tar command isnt finding the file, though its there
tar (child): xz: cannot exec: no such file or directory
I think free image needs to be the newer version. Does 3.16 have an x64 build? there arent any pre compiled binaries: http://sourceforge.net/projects/freeimage/files/Binary%20Distribution/3.16.0/ I know 3.17 has both architectures.
For the time being I am separating things into Win32 and x64 folders so that files dont overwrite each other
Free type upgrades and compiles fine in x64 and msvc 140 if I do it in visual studio using the vs2010 project. Ill try to do it by script but good to know its possible
Id be happy to fix up the Apothecary scripts for OS X / iOS for FreeImage to support FreeImage 3.17.0.
I had some custom fixes for it for Xcode and iOS / OS X which I submitted fixes for in August last year, they may be featured in the new build. Else I can repatch it with those changes.
Always best to stay up to date (especially since this is the first patch for FreeImage in a year)
Also if this solves the issues for the Windows builds then all the more need.
Sent from my iPhone
On 19 May 2015, at 9:57 am, Dominic Amato notifications@github.com wrote:
I think free image needs to be the newer version. Does 3.16 have an x64 build? there arent any pre compiled binaries: http://sourceforge.net/projects/freeimage/files/Binary%20Distribution/3.16.0/ I know 3.17 has both architectures.
For the time being I am separating things into Win32 and x64 folders so that files dont overwrite each other
— Reply to this email directly or view it on GitHub.
@ofTheo you would be the person to ask about this I assume.
videoInput builds fine in vs2015 but the project isn't configured for x64. An easy update of the project would make it buildable from the script
KISS doesn't need to be built for vs?
I think KISS is just build from the few C source code files (on platforms other than Linux/Linux ARM).
KISS is only used in linux to do the fft analisys on the sound player, other platforms use fmod so no need to compile it for vs
@danoli3 what about scripts for rtAudio? Newer versions support WASAPI and would be nice to have since I have actually run into issues where I had to recompile the rtAudio libraries. http://forum.openframeworks.cc/t/rtaudio-problems-in-win-8-1-in-of-0-8-0-fixed/14836/4
4.1.1 also supports cmake making building for vs2015 much easier
@LeoColomb is the cmake bugged? Everything compiled ok for me in both architectures
we need to use the same versions as the rest of the platforms since the include files have to be the same. if some library has newer versions which are significantly better or easier to build we can check it it's ok to change them in the rest of the platforms but we need to have all of them in sync.
that said rtaudio is usually really easy to build and the only other platform where we need to build it is in osx so it should be ok, just make sure to have the same version in both osx and windows.
for other libraries more platforms might need libs so be careful to not switch versions without agreeing with other platform maintainers first
right though rtaudio also doesnt build for vs2013/15 unless the code from their github is used. I guess the fix isn't a part of the download from the main site yet though the fix is several months old now.
Most of the libs have upgraded and compiled without issue. Cairo is being a bit problematic as i get an error when trying to unpack the tar.xz file. Manually unpacking things works but then the prepare function throws errors saying lib src dir pkg-config is missing. Perhaps these are issues with the git for windows bash? OpenSSL is also the next step. Currently the git bash doesn't handle comparing hashfiles but you can do it from command line in windows natively by running
cmd.exe /c 'call 'CertUtil' '-hashfile' '$FILENAME.tar.gz' 'SHA1''
though im not immediately sure how to get the output and then compare it against the downloaded SHA file but thats probably doable from the certUtil command as well. Either way I'll start work on the addons tonight probably.
Sounds like you've got some good momentum with the core @DomAmato I'm going to have a look at the 2 addons now, and head over to join you with Cairo if I get those done
can you clarify if you're building with Apothecary or by hand? Also do you have a copy of the libs you've successfully built so far? (something simple like a dropbox share might work). I'm elliotwoods (Seoul GMT+8) on Skype if you want to chat more directly
Assimp 3.0(?) x64 VS2015 lib assimp.lib
Build settings of OpenCV so far:
where are these kinds of settings customised in apothecary?
In addons/ofxOpenCv/scripts/formulas/OpenCV.sh you can see some of the flags we're passing for OS X including the CUDA etc
I struggled get OpenCv to build with apothecary on windows but mainly because cmake wasn't running with the correct permissions.
-DGLFW_BUILD_UNIVERSAL=ON \
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 \
-DCMAKE_OSX_ARCHITECTURES="x86_64" \
-DENABLE_FAST_MATH=ON \
-DCMAKE_CXX_FLAGS="-fvisibility-inlines-hidden -stdlib=libc++ -O3" \
-DCMAKE_C_FLAGS="-fvisibility-inlines-hidden -stdlib=libc++ -O3" \
-DCMAKE_BUILD_TYPE="Release" \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_DOCS=OFF \
-DBUILD_EXAMPLES=OFF \
-DBUILD_FAT_JAVA_LIB=OFF \
-DBUILD_JASPER=OFF \
-DBUILD_PACKAGE=OFF \
-DBUILD_opencv_java=OFF \
-DBUILD_opencv_python=OFF \
-DBUILD_opencv_apps=OFF \
-DBUILD_JPEG=OFF \
-DBUILD_PNG=OFF \
-DWITH_1394=OFF \
-DWITH_CARBON=OFF \
-DWITH_JPEG=OFF \
-DWITH_PNG=OFF \
-DWITH_FFMPEG=OFF \
-DWITH_OPENCL=OFF \
-DWITH_OPENCLAMDBLAS=OFF \
-DWITH_OPENCLAMDFFT=OFF \
-DWITH_GIGEAPI=OFF \
-DWITH_CUDA=OFF \
-DWITH_CUFFT=OFF \
-DWITH_JASPER=OFF \
-DWITH_LIBV4L=OFF \
-DWITH_IMAGEIO=OFF \
-DWITH_IPP=OFF \
-DWITH_OPENNI=OFF \
-DWITH_QT=OFF \
-DWITH_QUICKTIME=OFF \
-DWITH_V4L=OFF \
-DWITH_PVAPI=OFF \
-DBUILD_TESTS=OFF \
-DBUILD_PERF_TESTS=OFF >> "${LOG}" 2>&1
http://pointclouds.org/news/2011/08/29/ffast-math/ suggests that ENABLE_FAST_MATH might be a bad idea. Also not sure what performance gains it gives (also if those optimisations are actually performance gains on modern systems / common applications).
anyway will stick to these flags for the time being
i always thought it was a shame to build OpenCV without jpeg, png, ffmpeg, camera libs, etc but anyway i'm using ofxCvMin which has all those anyway
sticking to the program and building..
awesome @elliotwoods want to just do it as a PR and merge it in?
btw assimp should be the 3.0 version - I realized you asked this earlier.
we shoulnd't enable fast math on opencv. last time i tried it i think it completely broke face detection. fast math is really inacurate in terms of how float math is done
Sorry has been a crazy week. I have been compiling using the apothecary scripts. I will compile all the libraries I have gotten through and host them. Is mediafire ok?
Cairo and OpenSSL are the only ones remaining and openSSL has a bit of an odd build sequence. I think Perl isn't making the .MAK files properly so when I run nmake it says that install isn't a recognized command.
I was using this as a reference: http://p-nand-q.com/programming/windows/building_openssl_with_visual_studio_2013.html
@arturoc I think this fast math issue may be a problem on iOS. Just tested face tracker after reading this... definitely need to recompile. (Script has fast-math for iOS).
http://www.mediafire.com/download/f9sa4e9cfi99lnc
includes freeImage, freeType, glew, glfw, poco, rtaudio, tess2
also includes the updated scripts
portAudio and fmodex dont have build steps so there wasn't anything to update for those
I also need to update libpng, pixman, zlib, and pkg-config for Cairo
Could you put this in a branch for testing rather than mediafire?
https://github.com/DomAmato/openFrameworks/tree/VS2015Scripts
heres whats ive done so far
@DomAmato You rock! :smile: :clap:
Some notes:
static_md
libI noticed that too, I am patching the buildwin.cmd instead of using the cmake I will upload that as soon as I get it working
OK I updated the poco script. Instead of using cmake it replaces the buildwin.cmd file with one I patched. The patch creates a copy of the vs120 projects, renames it to vs140, upgrades them, and then builds them. Win32 worked and I am in the middle of running the x64 but there hasnt been any issues thus far.
OpenSSL should be good to go. It required a patch and I made a separate batch file though it could probably be handled in one shell script. Cairo is still being problematic. I've tried to follow this: http://www.cairographics.org/end_to_end_build_for_win32/
zlib is compilable via a cmake and so is libpng though there is also a vs project file that can be upgraded and compiled as well but not via command line. Not quite sure what is happening but trying:
vs-build libpng.vcproj "LIB Release"
results in an error
been busy till next week,are we targeting the VS2015 both 32&64?
I have been doing both. Apothecary has the ability to set the architecture to build for either so I don't see why we couldn't account for both
@DomAmato @elliotwoods thanks for all this handwork on the libs.
@DomAmato - could you do a PR for the branch you currently have. It will make it easier to see what is left to do. We can also merge in what you've done and then do a separate PR for Cairo.
@elliotwoods could you do a PR for OpenCV and Assimp?
Thanks!!
@DomAmato if getting Cairo building via script is tricky and holding things up feel free to build it manually and add the libs to #3876
Thanks!!
I will give it a push this week, I'm pretty confident it can be done easily enough just a matter of determining failure points and creating workarounds or patches
Just a quick clarification we just need the libpng and zlib LIB files to build cairo but they don't come packaged with OF? There is a zlib DLL file in the export folder but is that related or can it be a separate build step? As for Pixman and Cairo itself I think I will just make a static lib project in VS that can live in the scripts and be moved over and compiled rather than using the make scripts (which don't work with nmake)
Based off of this but updated to support newer versions of cairo: https://sites.google.com/site/slinavlee/
Bringing in:
Todo: