[Gdal-dev] Visual Studio "Makefile" Project

[Ivan Lucena]

Hi Symon,

You are right "clean" is absent on my message but it is there in the project.

And you are also right, that it is harmless. Not a big deal at all. 

Ivan

> ----- Original Message -----
> From: "Simon Perkins" <sy at perkins.net>
> To: "Ivan Lucena" <ivan at ilucena.net>
> Subject: Re: [Gdal-dev] Visual Studio "Makefile" Project
> Date: Fri, 19 Jan 2007 13:15:07 -0700
> 
> 
> Ivan Lucena wrote:
> > Folks,
> >
> > A Visual Studio Project for GDAL is now available in the SVN repository.
> >
> > It is a "Makefile Project" that is set to make calls to "nmake -f 
> > makefiel.vc".
> >
> > The settings are:
> >
> > - Build Command Line is :      "cd apps && nmake -f makefile.vc"
> > - Rebuild All Command Line is: "nmake -f makefile.vc"
> > - Clean Command Line is        "nmake -f makefile.vc"
> >
> I think that should be "nmake -f makefile.vc clean"...
> 
> 
> I guess this project file is relatively harmless, but I wonder if we're 
> putting too many different parallel build systems into the GDAL source tree. 
> There are already unix makefiles, Visual Studio makefiles, WinCE projects 
> files, and now this one. In addition, there are externally maintained VS 2003 
> project files to build GDAL directly. And of course if you run VS 2005 (hey, 
> this is 2007 after all...), then these project files all have to be converted 
> to the new VS 2005 to use them, and then changes can't be committed back to 
> the repository. Apart from the aesthetically unpleasing clutter, there's all 
> the effort that goes into maintaining these distinct build systems and 
> keeping them in sync with the source code.
> 
> Possible alternatives to storing these multiple build systems in the main 
> GDAL tree:
> 
> - Creating a contrib or extras directory in the GDAL main directory where 
> people can feel free to add builds scripts (and whatever else) for as many 
> different systems as they like.
> 
> - Creating a separate gdal-contrib SVN directory in parallel with gdal 
> directory where extras can go.
> 
> - Putting the effort into getting a true general purpose build system in 
> place such as cmake, which could then ultimately replace all the other build 
> scripts.
> 
> 
> Any thoughts?
> 
> Cheers,
> 
> Sy

>