Qt 4.3.2 vcproj generation annoyance

[spud]

I just started using qt-win-opensource-src-4.3.2 for windows and noticed some differences in the generation of MSVC workspaces from the patched versions I used before. Most of the changes are benign, like new warnings showing up, but I find a couple of things very annoying and I intend to gripe about them:
In my pro files I always add the following statement

CONFIG(debug, debug|release){
	TARGET = $$join(TARGET,,,_d)
}

CONFIG(debug, debug|release){
	TARGET = $$join(TARGET,,,_d)
}

To copy to clipboard, switch view to plain text mode 

so that I can use parallell release and debug builds. This works fine on linux and windows, creating libraries called NAME_d.dll or libNAME_d.so in debug mode. I'm just annoyed that the vcproj file ends up being called NAME_d.vcproj. Also my subdirs project always ends up generating "Makefile.sln" as opposed to "MyProject.sln"

Also, the recommended way of adding librarys like this:

LIBS += -Llibdir -llib1 -llib2 ...

LIBS += -Llibdir -llib1 -llib2 ...

To copy to clipboard, switch view to plain text mode 

doesn't seem to work with MSVC. I always end up having to write

unix:LIBS += -Llibdir -llib1 -llib2 ...
win32:LIBS += libdir/lib1.lib libdir/lib2.lib ...

unix:LIBS += -Llibdir -llib1 -llib2 ...
win32:LIBS += libdir/lib1.lib libdir/lib2.lib ...

To copy to clipboard, switch view to plain text mode 

And finally I would very much like the following to work with MSVC:

LIBRARIES     = blah blahh blahhh
 
CONFIG(release, debug|release){
	LIBS        += $$join(LIBRARIES, " -l", "-L../lib  -l",)
}
 
CONFIG(debug, debug|release){
	LIBS        += $$join(LIBRARIES, "_d -l", "-L../lib  -l", "_d")
	TARGET = $$join(TARGET,,,_d)
}

LIBRARIES     = blah blahh blahhh

CONFIG(release, debug|release){
	LIBS        += $$join(LIBRARIES, " -l", "-L../lib  -l",)
}

CONFIG(debug, debug|release){
	LIBS        += $$join(LIBRARIES, "_d -l", "-L../lib  -l", "_d")
	TARGET = $$join(TARGET,,,_d)
}

To copy to clipboard, switch view to plain text mode 

It would be so much easier if this would work and I could put it in a pri file. Then my pro files(more than twenty) would consist solely of an include statement, TARGET, LIBRARIES, HEADERS and SOURCES.

I've submitted this information to TT, but I'd like to hear if anybody else has any ideas or workarounds in the mean time.

[wysota]

I wouldn't use any workarounds. Qt 4.3.2 has a support for msvc built in into the opensource release (as opposed to earlier versions) so it might not be entirely stable. I've never heard of -L not working as it is qmake that provides the rule to transform -Lxxx statements into proper compiler switches. I suggest you wait for TT response. What version of the compiler are you using?

[AlGaN]

Hi spud,

I suppose you're using VC Express 2005. I'm using the opensource version of Qt 4.3.2 & I also noticed these changes in vcprog generation of qmake.

Unfortunately I don't have a workaround for these changes, but I compared vcproj xml file generated by qmake and noticed that default compiler settings have changed, projects now are generated with compiler switches

CRT_SECURE_NO_DEPRECATE,_CRT_NONSTDC_NO_DEPRECATE

meaning stricter settings for deprecated functions from standard library (like strcpy, sprintf,...)

I wrote this to Qt interest mailing list but there was no real statement from official TT folks to this issue.

Anyways, if you get any real solution or workaround I'd be glad to hear about it.

Regards,
AlGaN

[spud]

I've got an answer from TT and the first problem with the name of the .vcproj files is solved by using the undocumented scope build_pass, as in:

build_pass:CONFIG(debug, debug|release){
   TARGET = $$join(TARGET,,,_d)
 }

build_pass:CONFIG(debug, debug|release){
   TARGET = $$join(TARGET,,,_d)
 }

To copy to clipboard, switch view to plain text mode 

The problem with "$$join(LIBRARIES" seems to have been a mistake on my part.
Now it works fine for me. At least with 4.3.2.

@AlGaN:
I don't mind the new warnings as they are all valid warnings, which make my code more safe and portable, but the flags you mentioned actually tell the compiler not to warn about deprecated functions.