|
|
|
| Allegro 4.9.20 released |
|
Michał Cichoń
Member #11,736
March 2010
|
Uh! Evert did say that. Sorry Elias. Nevertheless, I agree with you. I wish to see simple interface to prepare builds. I will checkout scons, maybe some progress has been done. "God starts from scratch too" |
|
Trent Gamblin
Member #261
April 2000
 |
I think it's already been decided that scons is out, since python is too heavy a dependancy for a build system.
|
|
Elias
Member #358
May 2000
|
No, Python was not the problem, we actually had a scons build system for quite some time. It is out though for the reasons I said above (I don't think much has changed about that since then). -- |
|
Trent Gamblin
Member #261
April 2000
|
I'm sure python is and was part of the problem. Install python just to compile Allegro? That's a bit crazy, especially on Windows.
|
|
Evert
Member #794
November 2000
 |
Elias said: Myself I actually still have hopes for another build system as I don't like cmake one bit. It's much better than autotools though in every respect and also slightly better than scons.
What I meant is, fidling with the build system now that we have something that works well and works well on all platforms (issues with recent versions of MSVC and iPhone not withstanding) is not something we need to worry about (or should be worrying about) at the moment. As to CMake, I never was a big fan of it myself. However, having tried it out with some of my own code, I have found it to be ridiculously easy to set up a build system for it that worked properly across different platforms and was easy to maintain and extend. And that's for a project written in FORTRAN, which is generally less well supported than C. Michał Cichoń said: I wish to see simple interface to prepare builds. What's wrong with the CMake gui? |
|
Elias
Member #358
May 2000
|
Trent Gamblin said: I'm sure python is and was part of the problem. Install python just to compile Allegro? That's a bit crazy, especially on Windows. No, we had it for some time and it always worked. CMake is a heavier dependency (e.g. on OSX Python is pre-installed with the OS but CMake is an extra download). -- |
|
Michał Cichoń
Member #11,736
March 2010
|
Evert said: What's wrong with the CMake gui? With GUI? Nothing that I can complain at. To prepare release I need to set path to every library by hand, now multiply that by three (three compilers). I hope I don't lose those setups until next release. Probably I should write script to do such things, but I'm not experienced in CMake and/or shell scripting. There are some issues in *.cmake scripts: Where is FLAC_STATIC option? Could it be restored? DXGUID_LIBRARY and VORBISFILE_LIBRARY are ungrouped. "God starts from scratch too" |
|
Matthew Leverton
Supreme Loser
January 1999
 |
I don't know what CMake gives you on the Linux side of things, but for Windows it would be easier to just write a script that generates project files (like I did for 4.2). |
|
Trent Gamblin
Member #261
April 2000
|
Elias, I know we had it working, and it came up often in meetings that scons would not be the default and one of the reasons was it depends on Python. Matthew, isn't that exactly what cmake does?
|
|
Matthew Leverton
Supreme Loser
January 1999
|
Trent Gamblin said: Matthew, isn't that exactly what cmake does? In theory, yes. But CMake is ugly on all platforms and produces horrible MSVC project files (and broken MSVC 10 project files). Basically, if you want something that works well, you have to make it yourself. Creating an Allegro project builder for MSVC in PHP would only take me a few hours. Learning how to use CMake and fighting with its ridiculous syntax has already taken me more time than that. |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Matthew Leverton said: Basically, if you want something that works well, you have to make it yourself. Or instead of reinventing the wheel, yet again, you can try and help fix cmake. -- |
|
Trent Gamblin
Member #261
April 2000
|
I'd much rather have cmake generate projects than some fugly php script.
|
|
Elias
Member #358
May 2000
|
Trent Gamblin said: Elias, I know we had it working, and it came up often in meetings that scons would not be the default and one of the reasons was it depends on Python. I'm quite sure the idea was from the beginning that at the time we release A5 there would be only one build system, not multiple ones. CMake won over scons and that's why we removed scons... otherwise we would have removed cmake. -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
Thomas Fjellstrom said: Or instead of reinventing the wheel, yet again, you can try and help fix cmake. It's not about reinventing the wheel. It's about implementing what you need precisely for the task at hand. Recreating a high-level CMake would be foolish, as I would probably end up with the same set of problems. From my perspective, it's less effort to write a working build system directly for Allegro than fix CMake. Of course it's better for CMake if I were to fix it, but I would be doing this to make my life easier, not all of humanity. Trent Gamblin said: I'd much rather have cmake generate projects than some fugly php script. My PHP program is far less ugly than CMake and easier to maintain, even for somebody who knows nothing about PHP. Even a well written Perl script would be better than CMake when it comes to generating MSVC files for Allegro. |
|
Martin Kalbfuß
Member #9,131
October 2007
 |
I always thought, CMake is good for windows people http://remote-lisp.spdns.de -- my server side lisp interpreter |
|
Thomas Fjellstrom
Member #476
June 2000
|
Matthew Leverton said: My PHP program is far less ugly than CMake and easier to maintain, even for somebody who knows nothing about PHP. Even a well written Perl script would be better than CMake when it comes to generating MSVC files for Allegro. And KDevelop projects, and Code::Blocks projects, and Makefiles, and XCode projects? That much better eh? Allegro 4.2 and older had several build systems. what a nightmare to maintain. At least with CMake we have one thing to maintain. One. And in general, it just works. If not, we report a bug to CMake, and wait till they fix it (they are pretty good about fixing bugs afaik). -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
My goal is to make building MSVC binaries as easy as possible. Where have I even hinted at replacing Allegro's current system with a PHP build system that only supports MSVC or introducing multiple build systems into the official Allegro source? My point is simply for somebody like Michał or me, it is probably less hassle to just write a MSVC specific build system than mess around with CMake or some other general purpose tool. I did it for 4.2, and it was trivial. |
|
Peter Wang
Member #23
April 2000
|
Michał Cichoń said: To prepare release I need to set path to every library by hand, now multiply that by three (three compilers). This is indeed annoying. The main problem is the Windows practice of separating files by package, rather than by function. I have an idea to support a 'deps' directory under the main Allegro directory, where you could dump in any dependencies and CMake would be told to search in there. Any volunteers? (see below) Quote: Where is FLAC_STATIC option? Could it be restored? It is supposed to be set automatically now (addons/acodec/CMakeLists.txt line 97). Quote: I had to dig into *.cmake file to see that library should have '-static' suffix in name. I think I built a static FLAC library with the provided MSVC project file, and it was named with a _static suffix. If there is a better way to tell the difference between static and import libraries with MSVC, we can do that. EDIT2: tested with MinGW cross compiler under Linux only. 1diff --git a/CMakeLists.txt b/CMakeLists.txt
2index 6c91bfe..4a702ed 100644
3--- a/CMakeLists.txt
4+++ b/CMakeLists.txt
5@@ -36,6 +36,20 @@ set(ALLEGRO_DLL_SHORTVER 49)
6 # Search in the `cmake' directory for additional CMake modules.
7 list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
8
9+# Search in `deps' directories for dependency files.
10+file(GLOB deps_subdirs
11+ "${CMAKE_SOURCE_DIR}/deps"
12+ "${CMAKE_SOURCE_DIR}/deps/*"
13+ "${CMAKE_BINARY_DIR}/deps"
14+ "${CMAKE_BINARY_DIR}/deps/*"
15+ )
16+foreach(subdir ${deps_subdirs})
17+ if(EXISTS "${subdir}/include" OR EXISTS "${subdir}/lib")
18+ message(STATUS "Adding ${subdir} to CMAKE_FIND_ROOT_PATH")
19+ list(APPEND CMAKE_FIND_ROOT_PATH "${subdir}")
20+ endif()
21+endforeach(subdir)
22+
23 # Search for C header files in these directories.
24 include_directories(
25 ${CMAKE_SOURCE_DIR}/include
|
|
Mark Oates
Member #1,146
March 2001
 |
I tried running a program that would create and save a bitmap but the program would crash whenever I tried to draw to the bitmap. Even if I passed the ALLEGRO_MEMORY_BITMAP, I would still have to create the display to prevent anything from crashing. Is that the correct behavior? -- |
|
Trent Gamblin
Member #261
April 2000
|
Ah, that's a good reminder. We were supposed to add a dummy graphics driver so you could make command line tools. Some change (I forget which) made a display necessary.
|
|
Mark Oates
Member #1,146
March 2001
|
Wait... I found an actual bug? It's my first. Sweet. -- |
|
Michał Cichoń
Member #11,736
March 2010
|
Peter Wang said: This is indeed annoying. The main problem is the Windows practice of separating files by package, rather than by function. I have an idea to support a 'deps' directory under the main Allegro directory, where you could dump in any dependencies and CMake would be told to search in there. Any volunteers? (see below) This doesn't solve the problem entirely. In case of static libraries you need to compile them with specified compiler, so I need to put there binaries from VC8, VC9, VC10 and which one will be choose to link with? Peter Wang said:
Michał Cichoń said: Where is FLAC_STATIC option? Could it be restored? It is supposed to be set automatically now (addons/acodec/CMakeLists.txt line 97). It is not if someone compile libFLAC by itself. I didn't have a clue that Allegro require from dependencies to use strict naming scheme. Peter Wang said: I think I built a static FLAC library with the provided MSVC project file, and it was named with a _static suffix. If there is a better way to tell the difference between static and import libraries with MSVC, we can do that.
I don't know any method to distinguish between import and static libraries. They have even same format. Maybe using dlltool such detection is possible. "God starts from scratch too" |
|
Peter Wang
Member #23
April 2000
|
Michał Cichoń said: This doesn't solve the problem entirely. In case of static libraries you need to compile them with specified compiler, so I need to put there binaries from VC8, VC9, VC10 and which one will be choose to link with? The deps directory can either be in the source directory, or in the build directory. i.e. if you have a build directory for VC8 called Bvc8, then you would create Bvc8/deps. Under there you can have Bvc8/deps/include and Bvc8/deps/lib (or if you want, Bvc8/deps/<foo>/include and Bvc8/deps/<foo>/lib for any <foo>).
|
|
Michał Cichoń
Member #11,736
March 2010
|
Yap. This works for me in similar way. In my case all headers are in the original directories: Libs are compiled to: Finally I got: This work similar for other compilers/platforms. So you can see that simple 'deps' directory don't work very well for me, because I already have more complex situation. I think 'deps' will work if users download precompiled versions of dependent libraries. "God starts from scratch too" |
|
Thomas Fjellstrom
Member #476
June 2000
|
Michał Cichoń said: So you can see that simple 'deps' directory don't work very well for me, because I already have more complex situation. If you read a little more carefully, you'll see that it supports a deps directory in the BUILD folder as well. So you can put a deps dir inside \build\win32_vc8, and inside \build\win32_vc10 etc. -- |
|
|
|
