Tom Donovan wrote: > William A. Rowe, Jr. wrote: >> [EMAIL PROTECTED] wrote: >>> Author: tdonovan >>> Date: Wed Oct 15 05:24:25 2008 >>> New Revision: 704883 >>> >>> URL: http://svn.apache.org/viewvc?rev=704883&view=rev >>> Log: >>> Windows: add apr_dbd_odbc project to Visual Studio workspace .dsw file >> >> Hmmm? Guess I'm confused, we trigger _try_dbd in Makefile.win for the >> BuildBin >> target. We could default to building this as a dependency but it >> really isn't >> needed if _try_dbd sees a default "odbc" list, which could be a simple >> ifndef >> test of DBD_LIST. >> > More likely I'm the one confused. > > You are correct, this change isn't necessary for either a command-line > build using the generated .mak files (from the Windows .zip > distribution), or for an IDE build. > > _try_dbd works as you describe and it builds the odbc driver for the > BuildBin target. > > If there are no .mak files, the symbol USEDSW=1 is defined; then the > build uses: > > msdev Apache.dsw /USEENV /MAKE "apr_dbd_odbc - Win32 $(LONG)" > > which fails without an apr_dbd_odbc project in Apache.dsw. This can > happen if the source is from a snapshot or from svn, instead of from the > Windows source .zip file. > > It also seemed odd in the IDE to see a project for each of the other dbd > drivers, but no project for odbc. > > I couldn't see any disadvantage to having an apr_dbd_odbc project in > Apache.dsw, but maybe I'm missing something.
HA! Yes I was confused, too. apr_dbd_odbc must be added as a project. It does not become a -dependency- of any particular target. We'll always build it; we could leave it out of the _try_dbd default list. But since we can't imagine many users ever inspecting or changing that code and recompiling it with local changes, the _try_dbd solution is likely the simplest. At some point, it would be nice to add some decision making so that the others, beyond odbc, can be detected if they just reside somewhere in the LIB and INCLUDE paths :)
