|
MSVC 8 project file |
Matthew Leverton
Supreme Loser
January 1999
|
See this thread for the previous discussion (MSVC 6). Project files for MSVC 8 are now ready for testing. See the wiki page for instructions. Note that the project files only work with a custom version of 4.3.1 (available on the wiki). They build everything from Allegro to the tools and examples. If you have Visual Studio 2005 or Visual C++ Express 2005, please test it out. I recommend not copying the header and lib files to your VC directory, since it will overwrite your current version of Allegro. However, copying the alleg43.dll to your system folder will be required if you want to run any of the demos, etc. The project files were all generated by a script. The process has evolved into an "elaborate" mini PHP project that is actually capable of building all sorts of project files for any project. Originally it was just going to be a simple hacked together thing, but I came to the conclusion that doing a proper job would be better. Once everything is working properly, I'll be releasing the code as a stand-alone project. Some details are available on the wiki. |
BAF
Member #2,981
December 2002
|
Well, I'm getting compiler errors because I don't have DirectX SDK installed, so you may want to add that to the requirements. [edit] |
gillius
Member #119
April 2000
|
wiki site is down. If this works it would be nice to be able to compile Allegro in a pure MSVC environment. Gillius |
Timorg
Member #2,028
March 2002
|
The example on the wiki has "c:\allegro" and "C:\Program Files\Microsoft Visual Studio 8\" I am using I get the following errors when I build all the tools, everything else works fine. If allegro is inside the visual studio 8 directory (z:\msvc8\allegro\ in my case) it works fine. BAF said: Well, I'm getting compiler errors because I don't have DirectX SDK installed, so you may want to add that to the requirements. I found I didn't need the sdk, I just needed the minimal headers (dx70_min.zip) installed. On a side note, (if my memory is correct,) I can remember when the windows version of allegro needed visual studio to build it. Then it was made so that you could build it completely with free tools, now we are trying to fix it so that you can build it completely in visual studio. I guess allegro has come the full circle. ____________________________________________________________________________________________ |
Matthew Leverton
Supreme Loser
January 1999
|
Quote: I get the following errors when I build all the tools, everything else works fine. Those tools depend on aldat.lib, which you hadn't built yet. It won't be a problem once I fix the dependency checking (which used to be working until I changed some things around...). |
Timorg
Member #2,028
March 2002
|
I just ran over it again, your right, it fails on the 1st build, but if i run build again, everything comes out fine. I built it the 1st time not in the msvc directory, then I moved it, and compiled it again, and it worked. It was the dependency being build, not the moving that made it work. ____________________________________________________________________________________________ |
gillius
Member #119
April 2000
|
I'm sorry I'm not trying to sound critical, but CMake builds MSVC workspaces and a lot of other targets are possible as well. In GNE I was able to replace several versions of MSVC workspaces and Makefiles for several different systems as a single CMake system. The process of generating workspaces even in a high-level scripting language like PHP sounds like a non-trivial task, so I ask this out of curiosity. Gillius |
Matthew Leverton
Supreme Loser
January 1999
|
I used PHP because I know it, so it didn't take me long at all. However, if CMake can easily do the same thing, then surely someone will volunteer to do it. (They just haven't yet for some reason.) |
gillius
Member #119
April 2000
|
It's easy for someone who knows Allegro's structure and CMake. I did it for GNE but GNE is somewhat of a simple case. But that was my first CMake application so I "worked through it" with documentation. I'm sure Allegro is pretty achievable but CMake is probably not trivial enough for someone to do it. CMake is basically a logical replacement for automake in that it's a system that makes makefiles, but it can do MinGW, Linux, MSVC, nmake, etc. Gillius |
Peter Wang
Member #23
April 2000
|
Allegro 4.3 (4.9) has had a CMake build for about half a year now. It's mainly for the Unix port, although it did work with MinGW at one stage.
|
Timorg
Member #2,028
March 2002
|
Something has just occurred to me, When I build allegro, I build the dll version first, then I build the static version, so that all the examples and tools are statically linked, so I don't have to copy the dll into the directories to use them. I could copy the dll to the system directory, but I prefer not to do that, because then I get my system directory polluted, and if the dlls go out of date, applications might use the older version, and have things crash or what-not. Not sure the best way to fix this though, maybe have an alternative configuration set that will statically link, this will show up in the batch build window, but you would need to change the drop down box for every thing you want to build, or have twice as many items in the list, one for dynamic and one for static, and I'm not sure what would happen if you selected both. Just thinking out loud really. ____________________________________________________________________________________________ |
gillius
Member #119
April 2000
|
Peter: Well since CMake is designed to be portable, it should already work to generate MSVC workspaces. I guess it's possible to have it working only in one environment but I figure that's pretty hard to do. Then again I'm not a huge CMake guy -- I only did it once so I'm no expert. Gillius |
Peter Wang
Member #23
April 2000
|
It shouldn't be hard to make it work with MSVC, but I doubt it would work as-is. It's easy to miss a #define or two, or try to pull in a library that only exists on Linux, etc. We used to require some asm code on Windows, and CMake doesn't (didn't) have very good support for that, even with MinGW, so who knows what kind of hoops you had to jump through to get it to use gcc for a few files but MSVC for the rest. Matthew's recent changes should solve that problem at least.
|
Matt Smith
Member #783
November 2000
|
Well I finally got asmlock.asm ported fully, and it was a valuable learning experience. I learned the following things
My conclusion is therefore that the C code is the only viable solution, and so I will modify my 4.2 projects to match Matthew's 4.3.1 ones. I shaln't inflict my asmlock.asm on anyone ever again. I would suggest keeping the 386 gnu code indefinitely (at least in the 4.x branch), as this covers a lot of bases, and serves as a template should anyone fancy trying their hand at mmx (edit: duh already there for blit) or sse versions. |
ixilom
Member #7,167
April 2006
|
bump ___________________________________________ |
Matt Smith
Member #783
November 2000
|
GullRaDriel and I have both had problems with the GDI driver, which has been repainting incorrectly. I think I have discovered the reason. EDIT: rest of post deleted because it was all WRONG! |
GullRaDriel
Member #3,861
September 2003
|
And so now MattyMatt, is it working ? "Code is like shit - it only smells if it is not yours" |
Matt Smith
Member #783
November 2000
|
IT IS WORKING! src/win/wgdi.c line 52 --- Can I have my "I Am An Allegro Dev" badge now please? |
GullRaDriel
Member #3,861
September 2003
|
Cool ! So now do we have a full C version of allegro working ? (The important part is Full C ) EDIT due to irc speak: Yes it does, and it is Nice ;-) "Code is like shit - it only smells if it is not yours" |
|