Hi Jeff,
Thanks for looking into this. I tried the Visual Studio 9 and Visual Studio 11 generators in both standard Win32 and x64 forms. Both of these have similar problems even though the first uses .vcproj files and the late .vcxproj files. The cmake generated code is accepted by the resource compiler argument parser but then fails during the resource compile stage. It appears that the code does work for some cases where the long name only contains a single word, but it always fails when there are multiple words. Bert From: Jeff Trawick [mailto:traw...@gmail.com] Sent: maandag 18 november 2013 19:22 To: Apache HTTP Server Development List Subject: Re: Playing with cmake: LONG_NAME= problems On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben <b...@qqmail.nl <mailto:b...@qqmail.nl> > wrote: Hi, As I already mentioned I'm re-scripting my build of httpd to work using the new cmake generator. It looks like I have things working now, with about half as many local patches as before..., but I think one problem I had to patch around will be common for everybody using project files for Visual Studio 2005 and later: I don't doubt it, but just for fun: Exactly which generator/studio version were you using, in case I have a problem reproducing? The very ugly escaping of the LONG_NAME= argument. E.g. CMakeLists.txt contains: SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS "-DLONG_NAME=\"\\\"${mod_name} for Apache HTTP Server\\\"\" -DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS}") The long name value is then later generated in project files, but differently for the C compiler and the RC (=resource) compiler. This resource compiler doesn't like the way the value is generated, and just handles the value literally... And then generates parser errors. In Subversion where we used this same pattern for years, we avoided all the '"' escaping problems by using the APR_STRINGIFY() macro. That allows simply passing the value. We do that two, though with a little indirection: #define LONG_NAME_STR APR_STRINGIFY(LONG_NAME) #define BIN_NAME_STR APR_STRINGIFY(BIN_NAME) VALUE "FileDescription", LONG_NAME_STR "\0" VALUE "FileVersion", AP_SERVER_BASEREVISION "\0" VALUE "InternalName", BIN_NAME_STR "\0" VALUE "LegalCopyright", AP_SERVER_COPYRIGHT "\0" VALUE "OriginalFilename", BIN_NAME_STR "\0" I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try to put literal quotes there. E.g. BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904B0" BEGIN VALUE "CompanyName", "http://subversion.apache.org/\0 <http://subversion.apache.org/0> " VALUE "FileDescription", APR_STRINGIFY(SVN_FILE_DESCRIPTION) "\0" VALUE "FileVersion", SVN_VER_NUMBER "\0" VALUE "InternalName", "SVN\0" VALUE "LegalCopyright", "Copyright (c) The Apache Software Foundation\0" VALUE "OriginalFilename", APR_STRINGIFY(SVN_FILE_NAME) "\0" VALUE "ProductName", "Subversion\0" VALUE "ProductVersion", SVN_VERSION "\0" #ifdef SVN_SPECIALBUILD VALUE "SpecialBuild", SVN_SPECIALBUILD "\0" #endif END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END I've fixed the problem for me with a local hack, but I think many future users of the cmake build scripts would be very happy if this problem could be fixed in the standard scripts. In my case that would allow me to reduce my own patches, to cmake specific things. (E.g. I like to have .pdb files even for the fully optimized builds, and cmake doesn't support that scenario) Bert -- Born in Roswell... married an alien... http://emptyhammock.com/