httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Playing with cmake: LONG_NAME= problems
Date Mon, 18 Nov 2013 21:14:38 GMT
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben <bert@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:trawick@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 <bert@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/

Mime
View raw message