Playing with cmake: LONG_NAME= problems
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:
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.
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
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;
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/
RE: Playing with cmake: LONG_NAME= problems
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
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
mailto: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/
Re: Playing with cmake: LONG_NAME= problems
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/\0http://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/
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/\0http://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/
RE: Playing with cmake: LONG_NAME= problems
Hi Jeff,
I can confirm that this fixes the LONG_NAME problems :)
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:
PreprocessorDefinitionsWIN32;_WINDOWS;NDEBUG;APP_FILE;LONG_NAME=Apache
HTTP
Server;BIN_NAME=httpd.exe;ICON_FILE=F:/svn-dev/build/httpd/build/win32/apach
e.ico;CMAKE_INTDIR=\Release\;%(PreprocessorDefinitions)/PreprocessorDefin
itions
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
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
mailto:traw...@gmail.com wrote:
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben b...@qqmail.nl
mailto: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 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
mailto: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
Re: Playing with cmake: LONG_NAME= problems
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:
PreprocessorDefinitionsWIN32;_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/\0http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE
