|
This thread is locked; no one can reply to it. |
1
2
|
Prototype MSVC binaries |
SiegeLord
Member #7,827
October 2006
|
I've been spending my evenings coming up with a reliable procedure to generate binaries for Windows, starting with MSVC. This involves creating a CMake-based build system for 5 of the dependencies, and some minor patches to the existing CMake-based build systems of the remaining 5. While I figure out how to package those changes (and possibly figure out if I can reuse any of this for MinGW), I figured I'd get some of you MSVC users to test the output of this process. Prototype A5 MSVC 2013 binaries This package includes the dynamic and static builds for the primary allegro dependencies (no super-optional stuff like OpenAL), most coming in the form of a release binary with debug symbols. The exception for those are DUMB (it is static only) and libpng (it has no debug symbols). Allegro itself is included in triplicate: dynamic release+debug symbols, dynamic debug and static. Note that this is the WIP version of Allegro (the soon to be 5.1.10), and not any of the releases. This is just for testing. Try this out, tell me if anything is odd. If it all works out, I plan on using this procedure to create MSVC binaries for 5.1.10 release and on. If I have time, I might try to create some 5.0.10 binaries as well (that's a bit more work, since I'd need to patch some of Allegro's build files). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
GullRaDriel
Member #3,861
September 2003
|
Thanks for those using MSCV, though I don't ^^ "Code is like shit - it only smells if it is not yours" |
Elias
Member #358
May 2000
|
How hard would it be having a single library, like Mical used to provide? -- |
SiegeLord
Member #7,827
October 2006
|
The monolith library is an abomination, but since Allegro's CMake can produce it, it just means another compile or three. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Elias
Member #358
May 2000
|
Hm, I find the monolith better in just about every way... what is the problem you see with it? -- |
SiegeLord
Member #7,827
October 2006
|
It makes you lug around unnecessary DLLs (how often do you need libjpeg?) on all platforms. It is not in the Debian packages, so if you're porting from Windows, you're going to need to adjust your build script for no reason... in fact, it's a giant pain to support from other languages since you need to support both the regular libraries and the monolith, complicating the linking setup. On OSX, it links the main addon which is just plain wrong when you're not using C or C++. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Elias
Member #358
May 2000
|
Interesting. I like linking in everything, just for the convenience to not have to mess with the build system when I do need it. I did indeed use .jpeg images as background a few times, and they would just work without having to do anything As for extra DLLs, I thought Mikal's binary statically links things like libjpeg into the one big .dll? You do not need any other DLLs which is the beauty of it. This can also be done with Allegro's cmake build but you have to explicitly tell cmake to use the static libjpeg instead of the dynamic one. As for other languages, I always use the monolith version from Python and the main addon is no problem in OSX - when you dynamically load the .dylib it doesn't care if there's a main() function in there or not - dlopen() neither looks for it nor calls it And you don't have to support all the versions from another language - the monolith however should make it easier to do dynamic loading - you load just one library and expect all Allegro and dependency symbols in there, instead of requiring a list of which symbols are in which DLL. (The Python addon doesn't have such a list so if you do not use the monolith it will for example look up al_draw_line in each addon DLL...) Support from build systems (in something using Allegro) indeed is a problem, if you want it to build with the Debian Allegro then you of course have to use whatever version is available there. But that just means that instead of the monolith version you should also add support for the split version in that case. If you're too lazy to do that chances are your build system wouldn't work under Debian either way though And it's a matter of changing one line, instead of the "pkg-config allegro-monolith-static-debug-5 --static --libs" I have in my build system you'd replace it with the list of all the addons Debian has. -- |
SiegeLord
Member #7,827
October 2006
|
Alright, here's the source packages: https://github.com/SiegeLord/allegro_winpkg By following the readme in the msvc directory, it now should only take 10ish minutes to compile all the dependencies in 2 flavors and Allegro itself in a 8 flavors (monolith included this time). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Bruce Pascoe
Member #15,931
April 2015
|
Just want to chime in to say I use a monolith build of Allegro myself, except a static monolith--and wouldn't give it up for anything. I then link statically to all the dependencies (DUMB, libvorbis, etc.) and get a single-executable engine with no external dependencies which is around 2MB in size. I much prefer this, having only one lib for Allegro, than having to add 6-7 extra things to the link line. Even for dynamic builds, I've found that using the monolith is preferable if you're using more than 1-2 addons. The overall footprint ends up being smaller with the monolith than including the separate Allegro DLLs. Out of curiosity, are these built using the Windows XP toolchain (Project Settings -> Platform Toolset) or the default one? If using normal one, the resulting app won't work on anything older than Windows 7 due to a missing kernel32 export. I found this out the hard way recently and it's a big part of why I switched to building Allegro myself. The other reason: I needed a x64 build.
|
SiegeLord
Member #7,827
October 2006
|
These are built using whatever the default is... and they are 32 bit at the moment. The toolchain bit seems easy enough, not sure how 64 bit works. Contributions welcome . "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
is there a particular trick to this? I have downloaded and installed in Windows 8.1 64 bit nasm-2.11.08-installer.exe here is my path C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%Allegro5Dir%\bin;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\; C:\Users\Michael\AppData\Local\nasm;C:\Program Files (x86)\CMake\bin when I run build_deps.bat I get these errors when it gets to lib jpeg C:\allegro_winpkg-master\msvc\freetype-2.5.5\build>cd C:\allegro_winpkg-master\m C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0>mkdir build C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0>cd build C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build>cmake .. -DCMAKE_INSTALL C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build>cmake --build . --target Build started 4/25/2015 6:55:08 PM. Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ALL_BUILD.vcxp Done Building Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ Done Building Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ALL_BUILD.vcxp Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ALL_BUILD.vcxp Done Building Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ Done Building Project "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\ Build FAILED. "C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build\INSTALL.vcxproj" (defa 0 Warning(s) Time Elapsed 00:00:02.52 C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build>echo Failed with error # C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build>exit /b 1 C:\allegro_winpkg-master\msvc\libjpeg-turbo-1.4.0\build>
|
SiegeLord
Member #7,827
October 2006
|
Yeah, you need to put nasm into the PATH for the current scripts to work (i.e. just running nasm on the command line should work). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
C:\Users\Michael\AppData\Local\nasm; this is in my path near the end. is this wrong?
|
SiegeLord
Member #7,827
October 2006
|
If running 'nasm' like that doesn't work, then yes (you might also need to relaunch the terminal/windows explorer to pick up the PATH changes). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
Well I am embarassed to say I had a stupid space in my path. the deps build fine now. When I try to run build_allegro.bat i get several errors Project "C:\allegro_winpkg-master\msvc\allegro\build\ALL_BUILD.vcxproj" (2) is Project "C:\allegro_winpkg-master\msvc\allegro\build\ALL_BUILD.vcxproj" (2) is Done Building Project "C:\allegro_winpkg-master\msvc\allegro\build\ALL_BUILD.vc Done Building Project "C:\allegro_winpkg-master\msvc\allegro\build\INSTALL.vcxp Build FAILED. "C:\allegro_winpkg-master\msvc\allegro\build\INSTALL.vcxproj" (default target) 0 Warning(s) Time Elapsed 00:00:32.80 C:\allegro_winpkg-master\msvc\allegro\build>echo Failed with error #1. C:\allegro_winpkg-master\msvc\allegro\build>exit /b 1 C:\allegro_winpkg-master\msvc\allegro\build>
|
SiegeLord
Member #7,827
October 2006
|
That's... distressing. What version of Allegro are you building there? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
Trying 5.0.11 thats the version we have to use in class as its the last stable version
|
SiegeLord
Member #7,827
October 2006
|
Ah, I see. Looks like that's just broken in 5.0.11, sorry about that. Add these lines to allegro/src/file_stdio.c, immediately before #include <stdio.h> : #ifdef ALLEGRO_MSVC #include <windows.h> #define PATH_MAX MAX_PATH #endif
"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
thats was it. Compiled just fine after that. One last question. Once its all built. Where do I locate the Bin, Lib and Include directories? Nevermind. I found them
|
SiegeLord
Member #7,827
October 2006
|
Awesome! I've now updated the scripts to use the XP-compatible toolset and added scripts to generate the 64 bit binaries. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
Hrmm .. ok compiling 5.0.11 did not compile the monolith libs
|
Bruce Pascoe
Member #15,931
April 2015
|
@SiegeLord: Looks like you figured out how to generate the 64-bit binaries without my help. Basically you just have to add an additional "x64" platform target to the project alongside the Win32 one and MSVC will then the 64-bit compiler automatically for it. Since you're using default settings, I'm guessing these are linked dynamically to the MSVC runtime and not statically? MSVC builds are such a pain if you want to use anything other than the default settings (which you usually do) because you're forced to make the edits in the IDE. Out of curiosity, how far off is 5.1.10? I only ask because apparently the event queue bug I discovered in my other thread (the sound deadlocks) hasn't been fixed/reproduced yet...
|
SiegeLord
Member #7,827
October 2006
|
Bruce Pascoe said: Out of curiosity, how far off is 5.1.10? I only ask because apparently the event queue bug I discovered in my other thread (the sound deadlocks) hasn't been fixed/reproduced yet... Soon. I don't know if I'll get a chance to figure that bug out before that, but it'd be nice. Michael Branin said: Hrmm .. ok compiling 5.0.11 did not compile the monolith libs 5.0.11 does not have the monolith option (the 5.0.10 binaries were produces using a custom build script). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Michael Branin
Member #15,864
January 2015
|
well crap. I guess we will be sticking with 5.0.10 until a stable version of 5.1 is released.
|
SiegeLord
Member #7,827
October 2006
|
Aww, come on. The non-monolith builds are not that bad . "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
1
2
|