Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2F49110FDC for ; Mon, 18 Nov 2013 21:19:46 +0000 (UTC) Received: (qmail 60749 invoked by uid 500); 18 Nov 2013 21:19:45 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 60699 invoked by uid 500); 18 Nov 2013 21:19:45 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 60691 invoked by uid 99); 18 Nov 2013 21:19:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Nov 2013 21:19:45 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates 209.85.217.175 as permitted sender) Received: from [209.85.217.175] (HELO mail-lb0-f175.google.com) (209.85.217.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Nov 2013 21:19:41 +0000 Received: by mail-lb0-f175.google.com with SMTP id p9so5296593lbv.20 for ; Mon, 18 Nov 2013 13:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AiHpPDeMkiyPRdt4ZViGSks+PjAN/ePBheCVRFK8pPE=; b=e8ayySiFoE/M6UwoGtAKh2vAUhsqv5414Rakw9uFVLxBV9eonGi0Yw0lYvPIaeiEBK B9Ky1arRxgoxOcbekeoJf3D0STp83Ib2lEjIrgTYzSV6nSYEw1AxjG/d3MNnhKbPUP2k mwzzosnoAUa1yn7QT5HpLibQy8rerj/GzeXK6iefobKAoTPxNfYbEWwD3Os6k/lxg3gn OO9kgh3ZXg6+tpGrkCZJOWU+nLKf2FVTrF8N+CTRUsU/c/sPBf5DCuaMfhSrdS1yOkOq dfWlZFfRgNVOr1R4ByF+Hs03sHCej/3D5cROPo0JAJTcaNwpAzt0SS2QqKDkk43dHIB6 vuFQ== MIME-Version: 1.0 X-Received: by 10.112.144.105 with SMTP id sl9mr2825091lbb.37.1384809559785; Mon, 18 Nov 2013 13:19:19 -0800 (PST) Received: by 10.114.187.71 with HTTP; Mon, 18 Nov 2013 13:19:19 -0800 (PST) In-Reply-To: References: <036401cee484$d8173a60$8845af20$@qqmail.nl> <000201cee4a2$a780e400$f682ac00$@qqmail.nl> Date: Mon, 18 Nov 2013 16:19:19 -0500 Message-ID: Subject: Re: Playing with cmake: LONG_NAME= problems From: Jeff Trawick To: Apache HTTP Server Development List Content-Type: multipart/alternative; boundary=047d7b3a82f4e4896204eb7a193d X-Virus-Checked: Checked by ClamAV on apache.org --047d7b3a82f4e4896204eb7a193d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick wrote: > On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben 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 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 >> " >> 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/ --047d7b3a82f4e4896204eb7a193d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick <trawick@gm= ail.com> wrote:
On Mon, Nov 18, 2013 at= 4:10 PM, Bert Huijben <bert@qqmail.nl> wrote:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hi Jeff,

=A0

Thanks f= or looking into this.

=A0

I tried the Visual Studio 9 and Visual Studio 11 generators = in both standard Win32 and x64 forms. Both of these have similar problems e= ven though the first uses .vcproj files and the late .vcxproj files.=

=A0

The cmake generated code is accepted by the resource compiler argument pa= rser but then fails during the resource compile stage.

=A0

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 m= ultiple words.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bert


Cool... =A0In the meanti= me, I have a fix in trunk (r1543149) and am building the 2.4.x fix with Vis= ual Studio 2010 currently. =A0(Luckily exiftool makes it easy to quickly ch= eck File Description.)

r1543165 is the 2.4.x fi= x
=A0
=A0

=A0

= From:<= /b> Jeff Traw= ick [mailto:trawick@= gmail.com]
Sent: maandag 18 november 2013 19:22
To: Apache HTTP Serve= r Development List
Subject: Re: Playing with cmake: LONG_NAME=3D = problems

=A0

On Mon, Nov 18, 2013 at 12= :37 PM, Bert Huijben <bert@qqmail.nl> wrote:

=A0 =A0 =A0 =A0 Hi,

As I already mentioned I&= #39;m re-scripting my build of httpd to work using the
new cmake generat= or.

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 lat= er:

=A0=

I don't doubt it, but just for fun: E= xactly which generator/studio version were you using, in case I have a prob= lem reproducing?

=A0<= /u>

The very ugly escaping o= f the LONG_NAME=3D argument.

E.g. CMakeLists.txt contains:

SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
"-DL= ONG_NAME=3D\"\\\"${mod_name} for Apache HTTP Server\\\"\&quo= t;
-DBIN_NAME=3D${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 (=3Dresource) compiler. This
r= esource compiler doesn't like the way the value is generated, and just<= br>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.

=A0

We do that two, though with a little indirection:

=

=A0

#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)

=

#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)<= u>

=A0

=A0 =A0 =A0 VALUE "FileDescription", LONG_= NAME_STR "\0"

= =A0 =A0 =A0 VALUE "FileVersion", AP_SERVER_BASEREVISION "\0&= quot;

=A0 =A0 =A0 VALUE "InternalName"= ;, BIN_NAME_STR "\0"

=A0 =A0 =A0 VALUE "LegalCopyright", AP_SERVER_COPYRIGHT &q= uot;\0"

=A0 =A0 =A0 VALUE "OriginalFilename&= quot;, BIN_NAME_STR "\0"

=A0

I g= uess the LONG_NAME definition set in CMakeLists.txt doesn't need to try= to put literal quotes there.

=A0


E.g.

BEGIN
=A0 BLOCK "StringFileInfo"
=A0 BEGIN<= br>=A0 =A0 BLOCK "040904B0"
=A0 =A0 BEGIN
=A0 =A0 =A0 VALUE= "CompanyName", "http://subversion.apache.org/\0"
=A0 =A0 =A0 VALUE "FileDescription", APR_STRINGIFY(SVN_FILE_DESCR= IPTION) "\0"
=A0 =A0 =A0 VALUE "FileVersion", SVN_VE= R_NUMBER "\0"
=A0 =A0 =A0 VALUE "InternalName", &quo= t;SVN\0"
=A0 =A0 =A0 VALUE "LegalCopyright", "Copyright (c) The Apach= e Software
Foundation\0"
=A0 =A0 =A0 VALUE "OriginalFilenam= e", APR_STRINGIFY(SVN_FILE_NAME) "\0"
=A0 =A0 =A0 VALUE &= quot;ProductName", "Subversion\0"
=A0 =A0 =A0 VALUE "ProductVersion", SVN_VERSION "\0"#ifdef SVN_SPECIALBUILD
=A0 =A0 =A0 VALUE "SpecialBuild", SVN= _SPECIALBUILD "\0"
#endif
=A0 =A0 END
=A0 END
=A0 BLO= CK "VarFileInfo"
=A0 BEGIN
=A0 =A0 =A0VALUE "Translation", 0x409, 1200
=A0 E= ND
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 hav= e .pdb files even for the fully optimized builds,
and cmake doesn't = support that scenario)

=A0 =A0 =A0 =A0 Bert


=


=

=A0<= u>

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

=



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



--
Born in Rosw= ell... married an alien...
http://emptyhammock.com/
--047d7b3a82f4e4896204eb7a193d--