[Vxl-maintainers] RE: [Cmake] cmake/nmake/VC6.0/VXL

[Wheeler, Fred (CRD)]

Bill, Amitha,

Thanks for your suggestions.  I found the problem.

The cmake-produced nmake makefiles set NULL=nul.  This causes nmake to think that the sub-dirs do not
exist, so nmake does a rebuild-cache.  I was able to override this with a hack by setting the env var
OS to Windows_NT, which causes the makefiles to set NULL="".  Under cygwin, OS="1.3.10(0.51/3/2)",
whatever that means.

"nmake NULL=" did not work, I guess because the variable setting is not propagated to sub-makes.

Here is an example stanza that shows how NULL is used:

# Targets for making default_target in subdirectories.
default_target_vcl: $(TARGETS)
	if not exist "c:\Local\SR\vxl_bld\vcl\$(NULL)" $(MAKE) $(MAKESILENT) rebuild_cache
	echo Building default_target in directory c:/Local/SR/vxl_bld/vcl
	cd c:\Local\SR\vxl_bld\vcl
	$(MAKE) -$(MAKEFLAGS) $(MAKESILENT) default_target
	cd c:\Local\SR\vxl_bld

Here is how NULL is set near the top of the makefile

!IF "$(OS)" == "Windows_NT"
NULL=
!ELSE 
NULL=nul
!ENDIF 


Perhaps it is wishful thinking, but it would be nice to be able to use GNU make in cygwin and have it
use the VC6.0 compiler.

Regards,
Fred Wheeler

-----Original Message-----
From: William A. Hoffman [mailto:billlist at nycap.rr.com]
Sent: Tuesday, March 19, 2002 3:01 PM
To: Wheeler, Fred (CRD); 'Bill Hoffman'
Cc: 'cmake at public.kitware.com'; Vxl-maintainers (E-mail)
Subject: Re: [Vxl-maintainers] RE: [Cmake] cmake/nmake/VC6.0/VXL


If it is not the cache changing then try doing a nmake /D > log
Then look at the log file and try to figure out why it keeps running rebuild_cache.

-Bill


At 02:48 PM 3/19/2002 -0500, Wheeler, Fred (CRD) wrote:
>VXL-list:  Anyone else have problems with a top level cmake re-run for each directory traversed
>during a build with cygwin/cmake/nmake/MSVC6.0?  Does anyone else compile/use VXL in this
>environment?
>
>
>Bill,
>
>I tried your suggestion, but no luck.  The cache file did not change.  I tried wiping my build
>directory and starting a clean build also.  I can watch the cache file change a couple of times to
>add pointers to libraries that will appear in the build dirs, like this,
>
>  % diff CMakeCache_2.txt CMakeCache.txt
>  178c178
>  < NATIVE_JPEG_LIBRARY:FILEPATH=NOTFOUND
>  ---
>  > NATIVE_JPEG_LIBRARY:FILEPATH=c:/Local/SR/vxl_bld/v3p/jpeg
>
>But, generally the top level runs of cmake do not change the cache file.  The time stamp of the
cache
>file does not even change.
>
>The build commands I'm using are straightforward,
>
>  (in cygwin, SR is set to a directory)
>  cd $SR
>  rm -rf $SR/vxl_bld
>  mkdir $SR/vxl_bld
>  cd $SR/vxl_bld
>  cmake -G"NMake Makefiles" "C:\local\sr\vxl_src"
>  cp CMakeCache.txt CMakeCache_orig.txt
>  nmake
>
>Any other ideas?  Could something be changing the cache back-and-forth?
>
>The following output shows the end of one top-level cmake run, the building of a test exec, and the
>next top-level cmake run.
>
>
>  cmake: creating : c:/Local/SR/vxl_bld/conversions/math/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/conversions/math/tests/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/conversions/misc/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/conversions/misc/tests/Makefile
>  Building default_target in directory c:/Local/SR/vxl_bld/vxl/vul/io
>  c:\Local\SR\CMake\Source\cmake.exe -SC:\local\sr\vxl_src\vxl\vul\io -Oc:\Local\S
>  R\vxl_bld\vxl\vul\io -HC:\local\sr\vxl_src -Bc:\Local\SR\vxl_bld
>  'cmake.check_depends' is up-to-date
>  'cmake.depends' is up-to-date
>  cl /W3 /Zm1000 /GX /GR /MDd /Zi /Od /GZ -IC:\local\sr\vxl_src\vxl\vul\io -Ic:\Lo
>  cal\SR\vxl_bld\vcl -Ic:\Local\SR\vxl_bld\vxl -IC:\local\sr\vxl_src\vcl -IC:\loca
>  l\sr\vxl_src\vcl\config.win32-VC60 -IC:\local\sr\vxl_src\vxl -DVXL_WARN_DEPRECAT
>  ED -DVXL_WARN_DEPRECATED_ONCE -DVCL_WHERE_ROOT_DIR_H_EXISTS -c C:\local\sr\vxl_s
>  rc\vxl\vul\io\vul_io_user_info.cxx /Fovul_io_user_info.obj
>  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
>  Copyright (C) Microsoft Corp 1984-1998. All rights reserved. 
>
>  vul_io_user_info.cxx
>  lib /nologo @c:\DOCUME~1\wheeler\LOCALS~1\Temp\nma01124.
>  c:\Local\SR\CMake\Source\cmake.exe -HC:\local\sr\vxl_src -Bc:\Local\SR\vxl_bld
>  cmake: creating : c:/Local/SR/vxl_bld/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/vcl/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/vcl/tests/Makefile
>  cmake: creating : c:/Local/SR/vxl_bld/v3p/Makefile
>
>Thanks,
>Fred Wheeler
>
>
>
>-----Original Message-----
>From: Bill Hoffman [mailto:bill.hoffman at kitware.com]
>Sent: Tuesday, March 19, 2002 1:52 PM
>To: Wheeler, Fred (CRD); 'cmake at public.kitware.com'
>Subject: Re: [Cmake] cmake/nmake/VC6.0/VXL
>
>
>Usually, the cause of that is an unstable cache file.   
>If the cache file changes, cmake re-runs from the top automatically.
>It is sometimes possible to write cmakelist files that change the
>cache each time.   To debug this I would go to the top level directory,
>and do a make rebuild_cache, then make a copy of CMakeCache.txt, then run
>nmake.   If you see it running again from the top, then diff the CMakeCache.txt
>file with the backup and try to figure out what changed.
>Most of the time it is not possible to change the cache from a cmakelist file, so
>this is not a problem.
>
>
>-Bill
>
>
>At 01:23 PM 3/19/2002 -0500, Wheeler, Fred (CRD) wrote:
>>When I use cmake to compile VXL using nmake and VC6.0 in cygwin, cmake is rerun at the top level
and
>>recreates every Makefile every time the build enters a new directory.  Is this expected behavior?
>>
>>Thanks,
>>Fred Wheeler
>>_______________________________________________
>>Cmake mailing list
>>Cmake at public.kitware.com
>>http://public.kitware.com/mailman/listinfo/cmake 
>
>_______________________________________________
>Vxl-maintainers mailing list
>Vxl-maintainers at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers