Re: build-outputs.mk and generated headers

2013-06-04 Thread Guenter Knauf

Hi Bert,
On 03.06.2013 16:10, Bert Huijben wrote:

+1 this is a problem with cross compiling.

Spend a few hours multiple times to get an x64 build working on a Win32only
the problem is that usally gen_test_char.c includes the APR/APU headers 
for no real reason, an thwn will fail because target = x64 while build 
where gen_test_char.exe should run is x86; but you can try:

cl -DCROSS_COMPILE get_test_char.c
this should enable to build a gen_test_char.exe for the build platform 
without APR/APU headers but just those from PSDK, and then you can 
create the test_char.h manually, or probably it works if you put the exe 
into the source tree (and hopefully it will not be rebuild); or it may 
work too if you add the -DCROSS_COMPILE to the gen_test_char.dsp ...


Gün.







Re: build-outputs.mk and generated headers

2013-06-03 Thread Guenter Knauf

Hi Graham,
On 31.05.2013 23:34, Graham Leggett wrote:

I have been putting together an apr_escape API based on the escaping
and unescaping functions in httpd's util.c. So far so good. This code
depends on the generation of a file called test_char.h, which is
generated at build time by a small bit of code called
gen_test_char.c. Httpd handles this bit fine, I need to reproduce
this in the APR build.
I really dont like this; this gen_test_char.c thingy is one of the 
problems we have with cross-compiling, and from my view it is not needed.
If you look at the source of gen_test_char.c you can see that it usually 
includes the APR/APU headers only for getting some defines which are in 
ctype.h of each and every platform - so if we dont have these defines 
there, or no ctype.h at all for a platform, we simply can not support 
this platform.
Then gen_test_char.c is kinda matured, and has not received any 
significant updates, so the output of gen_test_char was probably 
identical over the past 10+ years (ok, I've not actually checked the svn 
logs, so I might be wrong). I believe we could just check in the result 
test_char.h into svn, and if we ever have to change it we can 
re-generate it with gen_test_char and update in svn; we do similar with 
the regex headers in httpd which also were a bit problematic because of 
different flex versions, and I think this works fine.


These are just my thoughts to tis topic - not a veto or such.

Gün.







RE: build-outputs.mk and generated headers

2013-06-03 Thread Bert Huijben


 -Original Message-
 From: Guenter Knauf [mailto:fua...@apache.org]
 Sent: maandag 3 juni 2013 09:12
 To: Graham Leggett; dev@apr.apache.org List
 Subject: Re: build-outputs.mk and generated headers
 
 Hi Graham,
 On 31.05.2013 23:34, Graham Leggett wrote:
  I have been putting together an apr_escape API based on the escaping
  and unescaping functions in httpd's util.c. So far so good. This code
  depends on the generation of a file called test_char.h, which is
  generated at build time by a small bit of code called
  gen_test_char.c. Httpd handles this bit fine, I need to reproduce
  this in the APR build.
 I really dont like this; this gen_test_char.c thingy is one of the
 problems we have with cross-compiling, and from my view it is not needed.
 If you look at the source of gen_test_char.c you can see that it usually
 includes the APR/APU headers only for getting some defines which are in
 ctype.h of each and every platform - so if we dont have these defines
 there, or no ctype.h at all for a platform, we simply can not support
 this platform.
 Then gen_test_char.c is kinda matured, and has not received any
 significant updates, so the output of gen_test_char was probably
 identical over the past 10+ years (ok, I've not actually checked the svn
 logs, so I might be wrong). I believe we could just check in the result
 test_char.h into svn, and if we ever have to change it we can
 re-generate it with gen_test_char and update in svn; we do similar with
 the regex headers in httpd which also were a bit problematic because of
 different flex versions, and I think this works fine.
 
 These are just my thoughts to tis topic - not a veto or such.

+1 this is a problem with cross compiling.

Spend a few hours multiple times to get an x64 build working on a Win32 only
VM.

Bert