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:19:19 GMT
On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick <trawick@gmail.com> wrote:

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

r1543165 is the 2.4.x fix


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



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message