I've uploaded a file here which contains all the dependencies (dlls, includes and libs) required to compile Allegro 4.9.8 for Microsoft Visual Studio 2005/2008.

The zip also contains a batch file which sets the environment variables appropriately.

A readme.txt included in the file explains everything.

In case anyone wants an alternative build try here. Also includes allegro in binary form for MSVC.

Any chance of a supplement to A5's installation instructions with that information? For the benefit of someone who wants to do this in the future?
In case I wasn't clear when I asked about this the first time: I think that's a necessary update for the documentation.

I think the most important points are:

1) rename libFLAC.lib to FLAC.lib.
2) rename libsndfile-1.lib to sndfile.lib.
3) also use vorbisfile.lib.
4) set up of the INCLUDE, LIB and PATH environment variables to point to the include files, libraries and dlls respectively. The paths should be added first before any other paths.

Manually renaming libraries sounds wrong. Are you sure there aren't some build settings somewhere that need to be modified instead? What part of the build process fails because it's looking for FLAC.lib and sndfile.lib instead of the actual libs?

It does not really matter if you rename the library. It's not the dll that it is renamed, only the 'lib' file, which is only used for informing the O/S linker about what symbol the dll contains.

I haven't found anything in the docs. Perhaps the allegro devs can enlighten us.

The VS solution file building process (i.e. when you call cmake).

Right, so we should just fix our FindFLAC.cmake and other files.

That's why I keep prodding you to submit a documentation patch...

I agree though, manually renaming libraries sounds wrong. Either there's a problem with Allegro's detection scripts, or somehow the installation on your system got messed up.

Documentation patch or fixing of cmake files?

Where did you get the lib*.lib files from? MSVC doesn't use the lib* naming convention, does it, so why should we be adjusting our build system for files that are named incorrectly? Besides, we just call FIND_LIBRARY which is a built-in macro/function, so if there's a bug anywhere it's there, but I highly doubt it.

The FLAC Windows binary package includes: libFLAC.dll, libFLAC.lib, etc.

Maybe it was designed for Mingw? Anyway, a patch like this might work:

diff --git a/cmake/FindFLAC.cmake b/cmake/FindFLAC.cmake
index 4d2a883..800a34f 100644
--- a/cmake/FindFLAC.cmake
+++ b/cmake/FindFLAC.cmake
@@ -12,7 +12,7 @@ endif(FLAC_INCLUDE_DIR)
 
 find_path(FLAC_INCLUDE_DIR FLAC/stream_decoder.h)
 
-find_library(FLAC_LIBRARY NAMES FLAC)
+find_library(FLAC_LIBRARY NAMES FLAC libFLAC)
 
 # Handle the QUIETLY and REQUIRED arguments and set FLAC_FOUND to TRUE if
 # all listed variables are TRUE.

I'm not sure that will work with MinGW.

That's incredibly stupid.
But I guess we'd have to work around that...

Can't we look for "FLAC" and "libFLAC", in that order?

Yes we could do that.

That was the intention of my patch (untested).

FLAC for Windows can be found here:

http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675&release_id=539572

It's the file flac-1.2.1-devel-win.zip.

I just committed something different but feel free to change it. It does it in a roundabout way but it does work.

I think theres a reason its called NAMES as in its plural.