Re: Fix to compile trunk on windows
On 9/11/06, Nicolas Lehuen <[EMAIL PROTECTED]> wrote: Sorry I usually don't use the VS GUI to build mod_python, only the dist/build_installer.bat script. I didn't even notice there was a VS .vcproject file until now :). That's why I haven't noticed the problem. Not your fault, probably mine for assuming the VS project was the way to go. I'm not familiar with the dist stuff, but probably it would work. I like to manage the compiler settings myself usually so I can turn on optimizations. Microsoft makes a pretty good optimizing compiler. In fact, I'm all in favor of dropping the VCPROJ file, because maintaining it could promptly become a mess, what with three differents version of VS to use (VS6 for Python 2.3, VS 2003 for Python 2.4 and who knows, VS 2005 one day ?). Anyone has an opinion on this ? Well I would miss it. But you can do something that would be better. Just make a text document with some cheat notes to help people get started building mod_python with their favourite compiler. I've included a sample of such a file, using it as a guide, I successfully created a new project from scratch and buuilt mod_python. You can use it as a base. -Dan compiling Description: Binary data
Re: Fix to compile trunk on windows
Dan Eloff wrote: Unrelated question, is it "ok" to use the trunk in a development environment? It will usualy work, or should I expect it to blow up in my face more often than not? At this point in the development cycle you are fairly safe. As later messages in this thread indicate you've been caught up in a problem with the Windows build environment rather that a mod_python bug. It's my personal opinion that trunk should always be in a fairly stable state so that people *can* use in their own development environment. That way we can catch problems that may be introduced early resulting in better and more timely releases. That being said, it is the development branch, and breakage may happen. :) Encouraging people to use trunk in their project development implies that we have some sort of a predictable release schedule. People won't like it if they use some new nifty feature in trunk but don't know when it might be available in a stable release for use in production. Just something to think about when we are planning our timelines. Jim
Re: Fix to compile trunk on windows
Jorey Bump wrote .. > Graham Dumpleton wrote: > > > The only area I guess one may have to be careful with is if you have > used > > PythonPath directive to extend module search path, especially if you > > reference directories in the document tree. This may result in mod_python > > complaining in the Apache error log at you and in worst case, if you > have > > Python packages in document tree, it will not find them. > > Can you clarify this a bit? Does it follow that the use of PythonPath to > extend the module search path to directories *outside* of the document > tree will still be safe? I use this extensively to isolate code to > virtual hosts. I *never* include packages or modules that exist in the > document tree in PythonPath, if that's a consideration. You can still use PythonPath for this purpose. Nothing found on PythonPath (sys.path) will though be a candidate for automatic module reloading. If you want any of those separate code modules to be candidates for automatic module reloading, then rather than using PythonPath, you should set the PythonOption mod_python.importer.path to the list of directories that the new importer should additionally search for reloadable modules. The path should be a full list of directories, you can't extend a list inherited from above and you shouldn't be putting sys.path in there either. In other words, there is a clear line between normal Python modules, which would be found in PythonPath (sys.path) and those which are managed by the new importer in mod_python. Standard Python modules in PythonPath (sys.path) are still stored in sys.modules and therefore must have unique names. Those managed by the new importer are NOT in sys.modules and are distinguished by a full pathname such that it is possible to have modules of the same name located in two different directories. The new importer tries to detect overlaps in the paths and will complain when it does. Because the new importer doesn't use sys.modules, the new importer can't look after Python packages, as sub imports within packages only work properly if the package is in sys.modules. As such, automatic reloading is not supported for Python packages and thus they have to be located on PythonPath (sys.path). There are alternate ways with the new module importer of managing package like groupings of modules where they are a part of the web application. Where PythonPath wasn't used, note that the directory associated with a handler directive is no longer added to sys.path. The new module importer determines through other means when it is necessary to search the handler directory for a module. The only consequence of the handler directory not being added to sys.path is that some separate module outside of the document tree found on PythonPath (sys.path) will no longer be able to perform a standard Python import to get hold of a module (such as a config module) from in the handler directory. This technique was always a bit unreliable anyway because of randomness in the sys.path and possibility the module name may have been used in different places with these places not being separated by using their own interpreter space. Overall, the changes were made to support what would be considered best practice ways of using the old importer. The new importer will complain though, by way of messages in the Apache error log, when questionable things are being down which could have resulted in an old application being potentially unstable. In these cases, the application may have to be restructured in a way to avoid the questionable practices. The one specific case which I am sure we are most likely to see is where someone has done: PythonPath "sys.path+['/some/internal/path','/some/external/path']" PythonHandler mptest SetHandler mod_python Strictly speaking, this was probably a limitation of old importer rather than something which was outright questionable in itself. Anyway, they have set PythonPath because they wanted some external path to be added to sys.path. Setting PythonPath though prevents the handler directory being added to sys.path, so they also added that manually. In the new importer it will complain in the Apache error logs about /some/internal/path appearing in sys.path but will otherwise still find mptest in /some/internal/path. It will do this though because the reloadable module will consist of that directory for the purposes of that request. The mptest module will be reloadable and not stored in sys.modules. The problem now comes if some module in sys.path imports mptest, because the internal path is in sys.path, it will find it, but that will become a separate copy of the module in memory stored in sys.modules. The solution here in the new importer is just to say: PythonPath "sys.path+['/some/external/path']" PythonHandler mptest SetHandler mod_python Ie., the internal path should not be added to sys.path. The new importer will still find mptest
Re: Fix to compile trunk on windows
Graham Dumpleton wrote: The only area I guess one may have to be careful with is if you have used PythonPath directive to extend module search path, especially if you reference directories in the document tree. This may result in mod_python complaining in the Apache error log at you and in worst case, if you have Python packages in document tree, it will not find them. Can you clarify this a bit? Does it follow that the use of PythonPath to extend the module search path to directories *outside* of the document tree will still be safe? I use this extensively to isolate code to virtual hosts. I *never* include packages or modules that exist in the document tree in PythonPath, if that's a consideration.
Re: Fix to compile trunk on windows
Dan Eloff wrote .. > I get the following linker errors when trying to compile mod_python as > fetched from the svn tonight. > > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_FromFinfo referenced in function _getreq_rec_fi > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_New referenced in function _mp_stat > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_Type referenced in function _setreq_recmbr > > The reason after some digging and coaxing the grey matter to life is > that finfoobject.c isn't added to the mod_python project. Silly of me > not to notice sooner. I don't have anything older than Visual Studio > 7, somebody else will have to fix it. My fault. Didn't realise I had to add files into studio build file for Win32. I thought compilation there was done using Python distutils setup.py file. :-( I don't have any access to Win32 to do it if it needs VS, will have to rely on Nicolas to add it and check. > Unrelated question, is it "ok" to use the trunk in a development > environment? It will usualy work, or should I expect it to blow up in > my face more often than not? I see no reason against using the trunk for development. Except for half a dozen more minor issues that need to be cleaned up, all major work for 3.3 has been done. Personally I'd like to think it is a lot more stable than version 3.2.10 is, especially with the new importer making that aspect of things work properly. The only area I guess one may have to be careful with is if you have used PythonPath directive to extend module search path, especially if you reference directories in the document tree. This may result in mod_python complaining in the Apache error log at you and in worst case, if you have Python packages in document tree, it will not find them. If you have any issues in the area of module importing, let us know and we can step you through any required configuration tweaks. Graham
