Forum Replies Created
-
Posts
-
IIRC, the makefile was needed to import the entire project and allow browsing it. Being fully custom allows to build/clean, but one will have to edit the files and search through them in a separate environment. Having to move back to Custom from GNUmake just because of that little issue doesn’t feel like a designed way, even if it is. It simply feels like a bug.
Maybe I missed a way to import the project with Custom?
But can all the compilation be moved to custom steps? As long as one uses a GNU makefile, any specific targets like mine won’t let the clean work peoperly. And it doesn’t get more complex if “clean” is put there by default.
Otherwise, instead of adding “clean” to the user’s “make” command, can it simply do just “clean” alone, while still working behind the scene? In that case custom clean won’t be needed.
I use a custom makefile indeed. And it does work alright from outside the MSVC. And I finally figured out the problem.
My make command contained a custom target, to skip building of the entire thing every time. And “make” runs well from both command line and MSVC. But whenever I execute “clean”, VisualGDB also seems to add that custom target to my command. Like, it doesn’t just tell make.exe to “clean”, but it uses the entire make command and adds “clean” to that. With no option to change it.
The log shows this difference:
VisualGDB: Run “C:\cygwin\bin\make.exe -f GNUmakefile CONFIG=Debug clean DEBUG=true” in directory “D:\SVN\midp\midp2.0fcs/build\win32\kvm” on local computer (TaskId:4)
VisualGDB: Run “C:\cygwin\bin\make.exe -f GNUmakefile CONFIG=Debug clean midp DEBUG=true” in directory “D:\SVN\midp\midp2.0fcs/build\win32\kvm” on local computer (TaskId:4)
I think the solution to this problem would be to allow the user specify a custom clean command too, since some of the arguments from “make” won’t make sense for “clean”.
