Re: [EMAIL PROTECTED]: Re: Broken APXS]

2007-07-23 Thread Farokh Irani

- Forwarded message from Eric Covener [EMAIL PROTECTED] -

On 7/22/07, Mike [EMAIL PROTECTED] wrote:

 Greetings.

 apxs accepts only *.c files as its input. For other extensions it
 doesn't invoke libtool in compile mode and several different issues
 leading to empty Apache module creation. The most probably reason is
 poor regex design.


This kind of invocation: $ apxs -cia mod_cpp.cpp other.C

Seems to behave better w/ the patch below:

http://people.apache.org/~covener/apxs-cpp.diff


When I tried to use patch with this, one hunk failed (#3) and the 
others appeared to be offset. Does anyone know if this diff file 
applies to the apxs with 2.2.4?


Thanks.
--

Farokh

MCF Software...simply dependably engineered
Developers of ListSTAR http://www.liststar.com/, MacRADIUS
http://www.macradius.com/, Address List Sorter
http://www.mcfsoftware.com/als/, SimpleText Filter for EIMS
http://www.mcfsoftware.com/stf/ and Auto Reply plug-in for EIMS 
http://www.mcfsoftware.com/ar/.


Re: [EMAIL PROTECTED]: Re: Broken APXS]

2007-07-23 Thread Mike

On 7/23/07, Farokh Irani [EMAIL PROTECTED] wrote:

http://people.apache.org/~covener/apxs-cpp.diff

When I tried to use patch with this, one hunk failed (#3) and the
others appeared to be offset. Does anyone know if this diff file
applies to the apxs with 2.2.4?
From diff file:


--- support/apxs.in (revision 555457)
+++ support/apxs.in (working copy)

so most probably this is patch for trunk version directly from svn repo.
Kind regards.


Re: Broken APXS

2007-07-23 Thread Joe Orton
On Sun, Jul 22, 2007 at 09:18:49AM -0400, Eric Covener wrote:
 On 7/22/07, Mike [EMAIL PROTECTED] wrote:
 Greetings.
 
 apxs accepts only *.c files as its input. For other extensions it
 doesn't invoke libtool in compile mode and several different issues
 leading to empty Apache module creation. The most probably reason is
 poor regex design.
 
 This kind of invocation: $ apxs -cia mod_cpp.cpp other.C
 
 Seems to behave better w/ the patch below:
 
 http://people.apache.org/~covener/apxs-cpp.diff

It's not portable to assume that $CC can compile anything other than C. 
Doing this properly means having configure detect a C++ compiler, 
getting CXX/CXXFLAGS passed through to apxs, mapping extensions to the 
correct compiler, maybe passing the libtool --tag option too where 
appropriate.

I'm not sure it's worth the complexity; it's already possible to pass 
.o/.lo to apxs (right?) so third-party modules can deal with the 
compilation step of non-C code.

joe


Re: Broken APXS

2007-07-23 Thread Mike

 apxs accepts only *.c files as its input. For other extensions it
 doesn't invoke libtool in compile mode and several different issues
 leading to empty Apache module creation. The most probably reason is
 poor regex design.
 This kind of invocation: $ apxs -cia mod_cpp.cpp other.C

 Seems to behave better w/ the patch below:

 http://people.apache.org/~covener/apxs-cpp.diff
It's not portable to assume that $CC can compile anything other than C.

It is because you can set CC to an arbitrary value.


I'm not sure it's worth the complexity; it's already possible to pass
.o/.lo to apxs (right?) so third-party modules can deal with the
compilation step of non-C code.

Well, the point is to extend apxs so it'll be able to compile and link
efficiently.
Kind regards.


[EMAIL PROTECTED]: Re: Broken APXS]

2007-07-22 Thread Mike
- Forwarded message from Eric Covener [EMAIL PROTECTED] -

On 7/22/07, Mike [EMAIL PROTECTED] wrote:
 Greetings.

 apxs accepts only *.c files as its input. For other extensions it
 doesn't invoke libtool in compile mode and several different issues
 leading to empty Apache module creation. The most probably reason is
 poor regex design.

This kind of invocation: $ apxs -cia mod_cpp.cpp other.C

Seems to behave better w/ the patch below:

http://people.apache.org/~covener/apxs-cpp.diff

| libtool --silent --mode=compile -c -o mod_cpp.lo mod_cpp.cpp
| libtool --silent --mode=compile -c -o other.lo other.C
| libtool --silent --mode=link gcc -o mod_cpp.la ...  other.lo mod_cpp.lo

-- 
Eric Covener

- End forwarded message -

Kind regards.


Re: Broken APXS

2007-07-22 Thread William A. Rowe, Jr.
Mike wrote:
 
 Where could I find current apxs maintainter?

Apache projects don't have component-maintainers the way you might
find in bsd and similar hierarchical organizations.

The good news is, you found the right place to bring this up.

Bill


Re: Broken APXS

2007-07-22 Thread Eric Covener

On 7/22/07, Mike [EMAIL PROTECTED] wrote:

Greetings.

apxs accepts only *.c files as its input. For other extensions it
doesn't invoke libtool in compile mode and several different issues
leading to empty Apache module creation. The most probably reason is
poor regex design.


This kind of invocation: $ apxs -cia mod_cpp.cpp other.C

Seems to behave better w/ the patch below:

http://people.apache.org/~covener/apxs-cpp.diff

| libtool --silent --mode=compile -c -o mod_cpp.lo mod_cpp.cpp
| libtool --silent --mode=compile -c -o other.lo other.C
| libtool --silent --mode=link gcc -o mod_cpp.la ...  other.lo mod_cpp.lo


--
Eric Covener
[EMAIL PROTECTED]


Re: Broken APXS

2007-07-22 Thread Nick Kew
On Sun, 22 Jul 2007 09:18:49 -0400
Eric Covener [EMAIL PROTECTED] wrote:


 Seems to behave better w/ the patch below:
 
 http://people.apache.org/~covener/apxs-cpp.diff

.cxx?  Modules in other languages?
How about adding an environment variable?  Something like:

-my $srcs_regex = '\.(' . join('|', @srcs_extensions) . ')$';
+my $srcs_regex = $ENV{'APXS_SRC_EXT'}
+ ? \. . $ENV{'APXS_SRC_EXT'} . $
+ : '\.(' . join('|', @srcs_extensions) . ')$';

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/


Re: Broken APXS

2007-07-22 Thread Mike
On Sun, Jul 22, 2007 at 09:18:49AM -0400, Eric Covener wrote:
 apxs accepts only *.c files as its input. For other extensions it
 doesn't invoke libtool in compile mode and several different issues
 leading to empty Apache module creation. The most probably reason is
 poor regex design.
 
  This kind of invocation: $ apxs -cia mod_cpp.cpp other.C
 
  Seems to behave better w/ the patch below:
 
  http://people.apache.org/~covener/apxs-cpp.diff
 
  | libtool --silent --mode=compile -c -o mod_cpp.lo mod_cpp.cpp
  | libtool --silent --mode=compile -c -o other.lo other.C
  | libtool --silent --mode=link gcc -o mod_cpp.la ...  other.lo mod_cpp.lo
Good. Also including this in next Apache release would be good idea.
Kind regards.


Re: Broken APXS

2007-07-22 Thread Mike
On Sun, Jul 22, 2007 at 02:32:21PM +0100, Nick Kew wrote:
 .cxx?  Modules in other languages?
Every shared-lib-compilable language (e. g. C++).

 How about adding an environment variable?  Something like:
 
 -my $srcs_regex = '\.(' . join('|', @srcs_extensions) . ')$';
 +my $srcs_regex = $ENV{'APXS_SRC_EXT'}
 + ? \. . $ENV{'APXS_SRC_EXT'} . $
 + : '\.(' . join('|', @srcs_extensions) . ')$';
Fixed extension is a bad idea. Sometimes ppl might have *.c and
*.cxx/*.cpp files together.
Kind regards.


Re: Broken APXS

2007-07-22 Thread Eric Covener

On 7/22/07, Nick Kew [EMAIL PROTECTED] wrote:

On Sun, 22 Jul 2007 09:18:49 -0400
Eric Covener [EMAIL PROTECTED] wrote:


 Seems to behave better w/ the patch below:

 http://people.apache.org/~covener/apxs-cpp.diff

.cxx?  Modules in other languages?
How about adding an environment variable?  Something like:

-my $srcs_regex = '\.(' . join('|', @srcs_extensions) . ')$';
+my $srcs_regex = $ENV{'APXS_SRC_EXT'}
+ ? \. . $ENV{'APXS_SRC_EXT'} . $
+ : '\.(' . join('|', @srcs_extensions) . ')$';



How about @opt_E to prepend (unshift) additional source extensions?

(will add cxx too)

--
Eric Covener
[EMAIL PROTECTED]


Re: Broken APXS

2007-07-22 Thread William A. Rowe, Jr.
Eric Covener wrote:
 On 7/22/07, Nick Kew [EMAIL PROTECTED] wrote:
 On Sun, 22 Jul 2007 09:18:49 -0400
 Eric Covener [EMAIL PROTECTED] wrote:

  Seems to behave better w/ the patch below:
 
  http://people.apache.org/~covener/apxs-cpp.diff

 .cxx?  Modules in other languages?
 How about adding an environment variable?
 
 How about @opt_E to prepend (unshift) additional source extensions?

My suggestion on modules-dev was to focus on the object and lib extensions,
a very short list that are usually acceptable to ld/libtool, and then having
the assumption that others are source files.  Right now, we pick up all known
source extensions, and assume any others are objects or libs.

In conjunction with Eric's patch above, it seems like a more comprehensive
fix.

Bill