+1 on Win32 with Python 2.4. Here is how I tested it :

1) Switched to the 3.2.0-BETA tag
2) Update
3) cd dist & build_installer.bat
4) Got this installer, that you can also download :

http://nicolas.lehuen.com/download/mod_python/mod_python-3.2.0-BETA.win32-py2.4.exe

5) Ran the installer, everything installed correctly
6) cd test & python test.py, all unit test pass
7) Used the test handler to check various version information
8) Made a few test this my own applications, everything seems OK (which is not a big surprise since I used the dev version before).

Regards,
Nicolas

2005/8/18, Jim Gallacher <[EMAIL PROTECTED]>:
Graham Dumpleton wrote:
> A few comments:
>
> 1. If you have an older version of flex than that expected, it gives
> message:
>
> checking flex version... configure: WARNING: Flex version 2.5.31 or
> greater is required.  The one you have seems to be 2.5.4. Use
> --with-flex to specify another.
>
> There is nothing in the README describing why such a requirement exists.
> The only veiled comment is in the "configure" script itself where it
> says:
>
>   # check for correct flex version
>   # requires flex 2.5.31 for reentrant support
>
> A more prominent explanation is required in the README with "configure"
> outputing with the message above a pointer to consult the README for
> further details.
>
> What also isn't at all clear, is whether the flex warning is relevant
> anyway if pre-generated code for the lexical analyser is provided in the
> tar ball and that is used.

This is explained in the html docs, but didn't make it into the README.
I wasn't sure if the WARNING was the right idea,



See doc-html/inst-configure.html:

"""   Attempts to locate flex and determine its version. If flex cannot
be found in your PATH configure  will fail. If the wrong version is
found configure will generate a warning. You can generally ignore this
warning unless you need to re-create src/psp_parser.c.

The parser used by psp (See 4.9) is written in C generated using flex.
This requires a reentrant version of flex which at this time is 2.5.31.
Most platforms however ship with version 2.5.4 which is not suitable, so
a pre-generated copy of psp_parser.c is included with the source. If you
do need to compile src/psp_parser.c you must get the correct flex version.

   If the first flex binary in the path is not suitable or not the one
desired you can specify an alternative location with the --with-flex
option, e.g:

     $ ./configure --with-flex=/usr/local/bin/flex

"""

I'll copy this into the README as well.

In 3.1.x the path to flex was hard coded to /usr/local/bin, which caused
  compilation to fail and required the user to edit the Makefile
manually.  Other than the detection of the flex path, the behaviour is
the same as 3.1.x. The previous warning about needing the correct flex
version was just a comment in the Makefile. Any suggestions on how to
make this clearer are welcome.

> Thus, what is the real story, am I going to have a problem or not if
> I have an older version of flex?

No, see html docs snippet above.

No time to look at the rest. Will comment tonight.

Jim

>
> 2. Publisher still doesn't check special extensions supplied by the
> AddHandler or PythonHandler directives. Ie.,
>
>   http://issues.apache.org/jira/browse/MODPYTHON-72
>
> This may mean that code that previously worked no longer works. Ie., this
> feature was in there before. Only caveat is that the feature may not have
> worked properly before anyway, so existing code may not be affected after
> all. See:
>
>   http://issues.apache.org/jira/browse/MODPYTHON-22
>
> Bit unsure on this one.
>
> 3. Only other issue at the moment I can think of is whether or not anything
> prominent has been put in main documentation about changed behaviour of
> module
> loading in mod_python.publisher. In the main the changes are for the better
> and things will actually work better.
>
> There is one case though where existing code can stop working. This is
> where
> code makes an assumption that global data within a publisher module is
> preserved
> across module reloads.
>
> I am not saying this change is wrong, but it perhaps may need to be clearly
> explained in documentation else we will get lots of questions about it
> no doubt, with the common answer probably being that they shouldn't be
> storing
> such persistent module data in a module that can be reloaded anyway.
>
> Thats all for now until I can get some real time to look at it. :-)
>
> Graham
>
>
>
> On 18/08/2005, at 4:03 AM, Jim Gallacher wrote:
>
>> Here are the rules:
>>
>> In order for a file to be officially announced, it has to be tested by
>> developers on the dev list. Anyone subscribed to this list can (and
>> should feel obligated to :-) ) test it, and provide feedback *to
>> _this_  list*! (Not the [EMAIL PROTECTED] list, and preferably
>> not me personally).
>>
>> The files are (temporarily) available here:
>>
>> http://www.modpython.org/dist/
>>
>> Please download it, then do the usual
>>
>> $ ./configure --with-apxs=/wherever/it/is
>> $ make
>> $ (su)
>> # make install
>>
>> Then (as non-root user!)
>>
>> $ cd test
>> $ python test.py
>>
>> And see if any tests fail. If they pass, send a +1 to the list, if they
>> fail, send the details (the versions of OS, Python and Apache, the test
>> output, and suggestions, if any).
>>
>> Thank you,
>>
>> Jim
>
>


Reply via email to