SDK makefile destroys source

Accelerated Computing CUDA CUDA Programming and Performance
#1

I just obliterated three days full of work switching to CUDA SDK 2.1.
This should be a lesson in not using given makefile-systems, but I don’t like writing makefiles at all and therefore was using the SDK-one.

There is a nice new rule for the keep target, which causes funny things - the line in question is:

NVCC_KEEP_CLEAN := .i *.cubin *.cu.c .cudafe *.fatbin.c *.ptx

Notice the new “.i”?

Guess what happens if you use an old convention of having inlined code in *.inl files in order to not pollute your headers?

Yes, that’s right: it destroys your code.

Nice…

1st of all dumping the intermediate files into CWD has always been a bad idea, but I used to live with it, since the extensions of the CUDA intermediate files used to be weird enough to trust that I won’t put anything called : *.cubin *.cu.c .cudafe *.fatbin.c *.ptx there myself, but any file that has some extension starting with an ‘i’ gets destroyed now, so watch out, if you are using the SDK-makefiles.

BTW. Maybe this affects osx version as well?

Stupid make and stupid rm…

#2

… stupid me…

#3

While I can see the frustration, surely you were just one ‘svn revert’ away from recovering your code…

#4

I was - the only problem is that I was looking for ways to improve the performance of my code and didn’t want to submit prototype code -

hence I lost only three days worth of code, but looking at it later, I lost only about 50% of that, since not all my changes were in inl-files.

Also it is always a lot faster to recover lost code simply rewriting it than it is to write it for the first time, so I could get to the point I was today, if I’m lucky.

:)

Modern version control tools lack a feature to backup a prototype changeset/list temporarily or locally, without polluting the main development branch (a branch as it exists is a overkill and I think that even Darcs doesn’t have a solution for this.

#5

(Getting off-topic) This is exactly what local branches are good for in a distributed version control system.