On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick <traw...@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben <b...@qqmail.nl> wrote: > >> 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 >> > > Cool... In the meantime, I have a fix in trunk (r1543149) and am building > the 2.4.x fix with Visual Studio 2010 currently. (Luckily exiftool makes > it easy to quickly check File Description.) > r1543165 is the 2.4.x fix > > >> >> >> *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> 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/ >> > > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > -- Born in Roswell... married an alien... http://emptyhammock.com/
