Revamping Python build system (Was: pythonXX.dll size: please split CJK codecs out)

[Giovanni Bajo]

Martin v. Löwis wrote:

>> Out of curiosity, was this ever discussed among Python developers?
>> Would something like scons qualify for this? OTOH, scons opens nasty
>> self-bootstrapping issues (being written itself in Python).
>
> No. The Windows build system must be integrated with Visual Studio.
> (Perhaps this is rather, "dunno: is it integrated with VS.NET 2003?")
> When developing on Windows, you really want all the support you can
> get from VS, e.g. when debugging, performing name completion, etc.
> To me, this makes it likely that only VS project files will work.

You seem to ignore the fact that scons can easily generate VS.NET projects. And
it does that by parsing the same file it could use to build the project
directly (by invoking your Visual Studio); and that very same file would be the
same under both Windows and UNIX.

And even if we disabled this feature and build the project directly from
command line, you could still edit your files with the Visual Studio
environment and debug them in there (since you are still compiling them with
Visual C, it's just scons invoking the compiler). You could even setup the
environment so that when you press CTRL+SHIFT+B (or F7, if you have the old
keybinding), it invokes scons and builds the project.

So, if the requirement is "integration with Visual Studio", that is not an
issue to switching to a different build process.

>> Before considering a patch (or even a PEP) for this, the basic
>> requirements should be made clear. I know portability among several
>> UNIX flavours is one, for instance. What are the others?
>
> Clearly, the starting requirement would be that you look at the build
> process *at all*.

I compiled Python several times under Windows (both 2.2.x and 2.3.x) using
Visual Studio 6, and one time under Linux. But I never investigated into it in
detail.

> The Windows build process and the Unix build process
> are completely different.

But there is no technical reason why it has to be so. I work on several
portable projects, and they use the same build process under both Windows and
Unix, while retaining full Visual Studio integration (I myself am a Visual
Studio user).

> Portability is desirable only for the Unix
> build process; however, you might find that it already meets your
> needs quite well.

Well, you came up with a maintenance problem: you told me that building more
external modules needs more effort. In a well-configured and fully-automated
build system, when you add a file you have to write its name only one time in a
project description file; if you want to build a dynamic library, you have to
add a single line. This would take care of both Windows and UNIX, both
compilation, packaging and installation.
-- 
Giovanni Bajo