On Mon, Nov 18, 2013 at 7:42 PM, Bert Huijben <b...@qqmail.nl> wrote:
> Hi Jeff, > > > > I can confirm that this fixes the LONG_NAME problems J > Great! > > > I have one remaining problem, that I hoped would be fixed by the same fix > you applied, but it wasn’t. > > > > If the httpd build directory contains a ‘-‘, such as in my case > ‘F:\svn-dev\build\httpd’, then the ICON_FILE argument doesn’t get through > as a valid token. > > > > [[ > > build\win32\httpd.rc(34): error RC2135: file not found: F:/svn > [F:\svn-dev\build\httpd\httpd.vcxproj] > > build\win32\httpd.rc(40): error RC2135: file not found: VERSIONINFO > [F:\svn-dev\build\httpd\httpd.vcxproj] > > build\win32\httpd.rc(41): error RC2135: file not found: 4 > [F:\svn-dev\build\httpd\httpd.vcxproj] > > build\win32\httpd.rc(42): error RC2135: file not found: PRODUCTVERSION > [F:\svn-dev\build\httpd\httpd.vcxproj] > > ]] > > > > The generated line in httpd.vcxproj is now: > > > <PreprocessorDefinitions>WIN32;_WINDOWS;NDEBUG;APP_FILE;LONG_NAME=Apache > HTTP > Server;BIN_NAME=httpd.exe;ICON_FILE=F:/svn-dev/build/httpd/build/win32/apache.ico;CMAKE_INTDIR=\"Release\";%(PreprocessorDefinitions)</PreprocessorDefinitions> > > > > I can fix this by updating the relevant lines in build/win32/httpd.rc from > > [[ > > #ifdef ICON_FILE > > 1 ICON DISCARDABLE ICON_FILE > > #endif > > ]] > > to > > #ifdef ICON_FILE > > 1 ICON DISCARDABLE APR_STRINGIFY(ICON_FILE) > > #endif > > > > Bert > Thanks! Trunk: r1543282 2.4.x: r1543283 This should be safe with the old build system too. ICON_FILE was passed in with the same syntax (quoting) as other values that were already APR_STRINGIFY-ed in the .rc file. > > *From:* Jeff Trawick [mailto:traw...@gmail.com] > *Sent:* maandag 18 november 2013 22:19 > > *To:* Apache HTTP Server Development List > *Subject:* Re: Playing with cmake: LONG_NAME= problems > > > > 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/ > -- Born in Roswell... married an alien... http://emptyhammock.com/
