win32 nmake clean leaves libsnmp files

Logged In: YES
user_id=85836

See patch: [ 971113 ] win32 nmake clean leaves libsnmp files

Logged In: YES
user_id=88697

Ran win32\build, using the default options.
make clean did remove the files from libsnmp\release.

Ran win32\build again, this time, built the Perl modules.
nmake clean did not visit libsnmp, therefore the files

were left.
libsnmp_dll is visited, which is correct, as you had to
build the DLL for the purpose of linking with the Perl
modules.

  I believe that the clean done prior to changing

net-snmp-config.h
is where you want to visit libsnmp

------
Unrelated questions

Why does "nmake clean" try to locate the "*.dsp" files ?
IMO, it should not, even though no ".dsp" files were removed.

There is an additional warning that should not occur.
See console output fragment below.

***** a portion of "nmake clean" output *****
cd libnetsnmptrapd
nmake /nologo clean
Warning: cannot find "libnetsnmptrapd.dep"
Could Not Find
C:\lm\net-snmp\pre1w\win32\libnetsnmptrapd\release\watcher.obj
cd ..
**** end "nmake clean" output ****

Logged In: YES
user_id=85836

Without the patch, a 'nmake clean' will clean all files from
the current configuration. This means if the current
configuation is 'static' then it will only clean the
'static' libsnmp.

The patch changes it so it cleans both the 'static' and
'dynamic' libsnmp with a win32\ 'nmake clean'.

Is that the correct behaviour, or should it only clean the
files from it's current configuration?

I think I should only clean what needs to be cleaned before
building so I don't think I should clean the static before
it builds the dyamic for Perl.

At the start of the script, it does a 'global' clean which
with the patch would clean everything regarless of the
current configuration.

So again, my question is: Should a global 'nmake clean'
only clean the files from it's current configuration or from
all configurations?

I don't think nmake clean looks for .dsp files. It looks
for .dep files, but that is from nmake, not from the script.
By default it looks for .dep files and I don't think it can
be turned off (?).

Logged In: YES
user_id=88697

My mistake -- You are correct --
nmake clean does NOT hunt for ".DSP" files.
It would be nicer not to see those messages,
but nice is not a reason to fix :-)

The patch gives the desired behavior of
cleaning all configurations. It is noisy,
for when the non-Perl build is made.
*** nmake clean output ***
cd libsnmp
nmake /nologo clean
Warning: cannot find "libsnmp.dep"
cd ..
cd libsnmp_dll
nmake /nologo clean
Warning: cannot find "libsnmp_dll.dep"
The system cannot find the file specified.
[SNIP] previous line repeats approx. 30 times
*** end nmake clean output ***

I thought that the "-" in front of each "erase" line
would execute that command quietly? Oh well.

If possible, showing fewer messages would be better,
so if "nmake" does not show the
"Warning: could not find XXX.DEP" messages,
that would be preferred.

Logged In: YES
user_id=88697

fixed by applying patch 971113

Logged In: YES
user_id=88697

set NO_EXTERNAL_DEPS=1
the above line will prevent warnings about *.DEP files

The bug persists today. I think we had both agreed that
always visiting all of the subdirectories would generate
warnings
about non-existent ".OBJ" or ".LIB" files. At the time this was
closed, I believe we agreed the noise was not worth the trouble.

I've come to a new understanding about this, and believe that
it is OK to be noisy.

I think that the warnings are appropriate.

I think that the directories should be visited, so that
"nmake clean" really cleans all of the targets within the
win32 subdirectory. To run "nmake clean" even if no
targets exist should be noisy, but should always be successful.

NOTE: if "nmake clean" would invoke "nmake realclean"
in the perl subdirs, the Makefile.old files will be removed.