[Gdal-dev] GDAL with Kakadu, and Windows build environments in general

Martin Daly Martin.Daly at cadcorp.com
Thu Aug 7 09:51:01 EDT 2003


All,

We recently paid our $$$$-s, and got Kakadu 4.0.2 for use with GDAL.  It
was not immediately obvious which parts of the Kakadu source tree were
required by GDAL, but, with some trial and error, I managed to generate
the list attached to this e-mail.  Hopefully the list will save any of
you who are considering using Kakadu with GDAL from going through the
same trial and error period.

Moving on to Windows build environments.  There has been some traffic on
this list recently on this very subject, so I thought I would share with
you the technique that we have ended up using, which may also be of use
to some of you.

Waybackwhen, I suggested to Frank wholesale changes to the makefiles to
make GDAL build the way I wanted.  Frank - quite rightly - said no.
After a couple of plainly useless schemes, I now keep the GDAL source
tree as-is, straight out of CVS, then checked in to Visual SourceSafe.
I have a very simple .BAT file that does a tree copy (XCOPY), with flags
that ensure that file times aren't modified - so that nmake doesn't
rebuild everything everytime.  The .BAT then copies over nmake.opt with
the one of my choice - my flags, my set of formats, etc. - and does an
nmake in the copied tree.  Apart from giving me the configurations that
I want, it also means that we can have "Debug" (/MDd for us) and
"Release" (both /MD and /MT) builds co-existing.  It also means that a
"clean" is simply a folder deletion, which is fast.

I have also used this technique with the Kakadu source.  So, using the
same XCOPY plus different nmake.opt-s, I am able to get the build
results I want.  My multiple GDAL nmake.opt-s now know about the
multiple build trees of Kakadu, and everyone is happy.  I would
definitely recommend this pattern when using the Microsoft tools.  It
just deals with all of the mixed compiler option problems that some of
you have been coming across recently.  It also solves the problem of
using the same name for both Debug and Release DLL-s, because they are
always in separate folders.

If any of you are interested in more details, then please get in touch.

Regards,
Martin Daly
Technical Director,
Cadcorp Ltd
-------------- next part --------------
analysis.cpp
analysis_local.h
blocks.cpp
block_coding_common.cpp
block_coding_common.h
block_decoder.cpp
block_encoder.cpp
cache_local.h
client_local.h
client_server.cpp
client_server_comms.cpp
client_server_comms.h
codestream.cpp
colour.cpp
compressed.cpp
compressed_local.h
decoder.cpp
encoder.cpp
jp2.cpp
jp2.h
jp2_local.h
jp2_shared.h
kdu_block_coding.h
kdu_cache.cpp
kdu_cache.h
kdu_client.cpp
kdu_client.h
kdu_client_window.h
kdu_compressed.h
kdu_elementary.h
kdu_file_io.h
kdu_image.h
kdu_kernels.h
kdu_messaging.h
kdu_params.h
kdu_roi_processing.h
kdu_sample_processing.h
kdu_utils.h
kernels.cpp
messaging.cpp
mq_decoder.cpp
mq_decoder.h
mq_encoder.cpp
mq_encoder.h
msvc_block_decode_asm.h
msvc_colour_mmx_local.h
msvc_dwt_mmx_local.h
palette.cpp
params.cpp
params_local.h
roi.cpp
roi_local.h
roi_sources.cpp
roi_sources.h
synthesis.cpp
synthesis_local.h
transform_local.h


More information about the Gdal-dev mailing list