Hi,
Dave McCaldon schrieb:
> I completely agree with you, nmake makefiles should work on any version
> of VS or VC way back to at least VC 6.0 and it should be pretty easy to
> support compilers for AMD64 and Itanium via the usual CFLAGS type variables.
and to adapt for other paths which is always a pain with project files ...
anywa, I looked yesterday into libssh2-1.1 release, and was suprised
that the NMakefile in the win32 folder didnt make it into release; I've
not checked it is still in GIT, but I'm 100% sure that I build libssh2
around v0.17 still with MSVC and NMakefile; now there's only one
NMakefile in the project root which wants to call the one in win32 and
(not checked, but guessed) the one which was in the test folder.
>
>> So I would drop the *.dsp at all - a proper nmake makefile is far easier
>> to maintain than those crappy project files - beside this _only_ nmake
>> makefiles can be used at all for any kind of automatic builds.
yes, well, probably this was some hard spoken; and I agree to keep them
as long as they are build by the dist script as it goes with libcurl;
just what I wanted to say is that for a developer - even if he lives on
Win32 with MSVC - the commandline should be acceptable since building
the lib is a one-shot thingy; if someone would _develop_ on libssh2 then
the project files would be of use, agreed; but since 99% only want to
build it and then link against in their own project there's really no
need for project files, and the IDE has no benefit at all.
There are really cool things out for Win32 like f.e. the DosHere shell
extension which enables you to launch a CMD box everywhere in your
directory tree just with a right-click on the folder, and then -
provided we would have working NMakefiles - you only would need to call
'vcvars32.bat' and then nmake '-f Nmakefile' and the lib would build; to
me this is far quicker and easier than launching the IDE and mess up
with project files. Also, if the NMakefile would be clever it would
allow to overwrite all vars from environment, so there would never be a
need to edit the NMakefile self, just creating a *.bat / *.cmd file
would do which sets the needed vars, calls vcvars32, and then executes
nmake.
Please, if you have some time, verify that the NMakefile still works; it
sits in the project root, and I have just build a libssh2.dll
successfully with it with MSVC6 from commandline - though nothing more
tested, and it probably needs also some tweaking.
> It is possible to invoke Visual Studio via the command line using the
> 'devenv' tool; it goes something like this:
>
> devenv myproject.vcproj /useenv /build "debug|Win32"
>
> Now the "debug|Win32" allows you to specify the build configuration
> (i.e. debug vs release) and also the build target, in this case Win32,
> but it could be "x64" or "Itanium" (assuming you have defined those
> targets in the project).
yes, thats what I had in mind ...
>> I've never tested, but probably its even possible to call the MSVC IDE
>> from a batch and instruct it via args to automatically read the
>> nmakefile and convert it to a project file ...
>
> I think that the last time I tried that (way back with VC 6.0), what it
> did was simply wrap the makefile in a dsp (i.e. the DSP contained no
> commands other than to execute nmake against the makefile, it didn't
> "read" the makefile and generate the equivalent dsp project).
yes, probably, though the question is 'do we need more here?' ...
also, it seems to me that currently here are some around who at least
know well about their compiler environment, and about alternatives;
I have too often seen that the win32 developer knowledge only reaches
up to douple-clicking a *.dsw file, and if that doesnt work without any
adjusting they are lost ... :)
@Peter:
please commit the *.dsp stuff - it cant get worser - currently the
existing are broken, so lets see if the patch works with next snapshot,
at least we have two win32 devels who can and want verify ...
Günter.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2009-07-15