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.) > > > *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/
