used it for years - it was the default solution, as it was already there. Had it bite me quite a few times, but inertia is difficult to overcome

then i had to use it remotely over VPN, and even minor check-ins were like stuffing a brick through a pinhole. It was faster to manually find the files that changed, zip them up, email them, remote in to the source vault machine, unzip them, and check in the code from the source vault machine.

Switched to Mercurial. I can clone the entire source code base across the VPN in under a minute. And I no longer fear branching.

Never going back.

Is SourceSafe really safe?
I have an issue with "make" (Oh, the horror!). 

We're trying to migrate some COBOL code from Windows to Linux. The compiler and such are from Micro Focus. Under Windows the code is developed with Micro Focus Net Express. Linux has Micro Focus Server Express as the equivalent. The programs are compiled and linked using "make" scripts. 

So much for the background.

The problem is a "make" script that doesn't want to compile and link an executable under Linux. The targets look like this:

# HP INIT-Daten laden
#
datLoad$O:   \
        $(UI)/defretrn.cpy \
        $(UI)/e12sy00s.cpy \
        $(UI)/e12sy005.cpy \
        $(UI)/e12sy006.cpy \
        $(UI)/e12sy010.cpy \
        $(UI)/e12sy013.cpy \
        $(UI)/e12sy050.cpy \
        $(UI)/e12db001.cpy \
        $(UI)/e12db050.cpy \
        $(UI)/evlg.cpy \
        $(UI)/deffehl.cpy \
        datLoad.xcbl $(FRC)
#       @echo "dollar-O is \"$O\" in $@"


datLoad$X:  $(LIBDSQL) datLoad$O \
        $(LP)/evlg$O $(LP)/alock$O
    $(LCOB) -o $(@:$X=) -e $(@:$X=) $(LCOBFLAGS) \
        -d e12db001 -d e12db003 -d e12db012 \
        -d e12sy005 -d e12sy006 -d e12sy009 \
        -d e12sy010 -d e12sy012 -d e12sy013 \
        -d e12sy050 \
        -I EvLgSetCategory $(LP)/evlg$O \
        -I ALckSetDebug $(LP)/alock$O \
        $(LIBEXEEXT) "$(LIBXSQL)"
    if [ -f $B/$@ -a ! -w $B/$@ ] ; then rm -f $B/$@ ; fi
    cp $@ $B


To put this into context, $0=".o" (i.e. an object file extension). $(LCOB) is the link command. $X=".exe" (an executable ... just forget about the extension, we'll fix that in due course). All the other stuff relates to paths ==> not relevant to the issue at hand and, yes, they've all been checked and verified.

Ultimately, I am trying to get "make" to resolve a target called "datLoad.o".

Included is a second "make" script containing the following:

COBFLAGS    = -cx # create object file
GNTFLAGS    =   -ug # create .gnt file
SOFLAGS     =   -z # create 
LCOB        = cob
...
.cbl$O:
    $(CCOB) $(COBFLAGS) $*.cbl, $*$O, NUL, NUL
    if [ -f $(LP)/$*$O -a ! -w $(LP)/$*$O ] ; then rm -f $(LP)/$*$O ; fi
    cp $*$O $(LP)


The relevant part is the target which resolves to ".cbl.o:". Yes, that's the shorthand version and I don't really like it but I did not write this script. I'm assured that it really means *.o:*.cbl and other similar constructs in the script do work correctly.

With a simple "make" I get a link error:

&gt; In function `cbi_entry_point': (.data+0x384): undefined reference to
&gt; `datLoad' /tmp/cobwZipkt/%cob0.o: In function `main': (.text+0x28):
&gt; undefined reference to `datLoad' make: *** [datLoad.exe] Error 1


That means datLoad.o was not created. If I do create it explicitly with:

 cob -cx datload


Then "make" still gives the same error as above. Weird! However, what I really cannot understand is the response I get from "make datLoad.o" when the target does not exist:

make: Nothing to be done for `datLoad.o'.


I assumed (heaven help me) that the target "datLoad.o" would try to create the required target file if that file does not already exist. Am I going mad?

Sorry if this seems a bit obscure, I'm not sure how to phrase it better. If anybody has an idea what might be going on, I'd be really grateful... 
