[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2008-10-05, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 5 Oct 2008, at 04:17, Peter Hull wrote:
> > In my mind the most important thing is to merge the fshook branch, the
> > the API is complete (I think) and we just need to work on implementing
> > missing functions in the platform-specific parts (for Mac, anyway,
> > others may already be done)
> >
> > The other thing is a more comprehensive 'test' program that we can use
> > to check all parts of the API are working properly. That's quite a job
> > in itself.
>
> I would like to add:
>
> * Cleaning up the naming scheme of kcm_audio (I can do this)
Cool.
> * Improving allegro5-config. I've looked at this a little bit
> (which reminds me, I need to commit a small cosmetic fix to
> CMakeLists.txt). The problem is that, right now, allegro5-config --
> libs gives me
> -L/Users/eglebbk/lib -lallegd_s-4.9.5 /System/Library/Frameworks/
> AppKit.framework /System/Library/Frameworks/IOKit.framework /System/
> Library/Frameworks/OpenGL.framework /System/Library/Frameworks/
> AGL.framework
> which is wrong (note that there is a version number on
> allegd_s-4.9.5, that was missing originally but it is present in the
> library name itself). Instead of listing the location of the
> frameworks it should say -framework OpenGL etc. CMake gets this right
> when compiling the examples, but for allegro5-config we grab the list
> of detected libraries from CMake itself, rather than the linker
> options CMake produces based on that list. Here I need a bit of help
> from someone who knows more about CMake than I do: how would I get
> that list of linker options from CMake?
I'm not sure how it's getting those /System paths right now.
Maybe echo out the PLATFORM_LIBS variable and the LIBS variable and see.
> As I've already mentioned, I'd also like `allegro5-config --libs --
> addon audio ttf iio...`, because that will a) safe me from having to
> work out what those are called and more importantly b) mean I don't
> have to figure out what external dependancies those depend on (-
> framework OpenAL comes to mind). That's again something I can do,
> once I've figured out the previous bit.
Would be nice.
> Another issue I'd like to bring up is documentation. Not for 4.9.6,
> but longer term (5.0, though we'll want to get this sorted out well
> before then).
> I probably missed part of the discussion here over the past few
> months, so if someone has a link to point me too, that's fine too.
> There are two things: the documentation itself and the format its in.
Elias pointed out Pandoc already. Version 1.0 was released not too long
ago, with Texinfo support ;-)
Actually, I had some trouble installing it due to some Haskell
dependencies. But it turns out the Window binary works fine in Wine...
Peter