On Fri, 10 Apr 2009 11:49:04 +1000, Neil Hodgson wrote:
>This means that generated Visual Studio project files will not work
> for other people unless a particular absolute build location is
> specified for everyone which will not suit most. Each person that wants
> to build Python will have t
On Mon, 30 Mar 2009 20:34:21 +0200, Christian Heimes wrote:
> Hallo Alexander!
>
> Alexander Neundorf wrote:
>> This of course depends on the definition of "as good as" ;-) Well, I
>> have met Windows-only developers which use CMake because it is able to
>> generate project files for different ve
Neil Hodgson wrote:
cmake does not produce relative paths in its generated make and
project files. There is an option CMAKE_USE_RELATIVE_PATHS which
appears to do this but the documentation says:
"""This option does not work for more complicated projects, and
relative paths are used when poss
cmake does not produce relative paths in its generated make and
project files. There is an option CMAKE_USE_RELATIVE_PATHS which
appears to do this but the documentation says:
"""This option does not work for more complicated projects, and
relative paths are used when possible. In general, it i
On Thu, Apr 9, 2009 at 4:45 AM, Alexander Neundorf
wrote:
> I think cmake can do all of the above (cpack supports creating packages).
I am sure it is - it is just a lot of work, specially if you want to
stay compatible with distutils-built extensions :)
cheers,
David
__
>> - registration to pypi
Alex> No idea what this is .
http://pypi.python.org/
It is, in some ways, a CPAN-like system for Python.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Wed, Apr 8, 2009 at 4:18 AM, David Cournapeau wrote:
...
>> I guess something similar could be useful for Python, maybe this is
>> what distutils actually do ?
>
> distutils does roughly everything that autotools does, and more:
> - configuration: not often used in extensions, we (numpy) are t
On Wed, Apr 8, 2009 at 7:54 AM, Alexander Neundorf
wrote:
> On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing
> wrote:
>> David Cournapeau wrote:
>>>
>>> Having a full
>>> fledged language for complex builds is nice, I think most familiar
>>> with complex makefiles would agree with this.
>>
>> Yes, pe
On Wed, Apr 8, 2009 at 6:42 AM, Alexander Neundorf
wrote:
> What options ?
Compilation options. If you build an extension with distutils, the
extension is built with the same flags as the ones used by python, the
options are taken from distutils.sysconfig (except for MS compilers,
which has its
Alexander Neundorf wrote:
My experience is that people don't need
general computation in their build process.
> ...
CMake supports now more general purpose programming features than it
did 2 years ago, e.g. it has now functions with local variables, it
can do simple math, regexps and other thin
On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing wrote:
> David Cournapeau wrote:
>>
>> Having a full
>> fledged language for complex builds is nice, I think most familiar
>> with complex makefiles would agree with this.
>
> Yes, people will still need general computation in their
> build process from
David Cournapeau wrote:
Having a full
fledged language for complex builds is nice, I think most familiar
with complex makefiles would agree with this.
Yes, people will still need general computation in their
build process from time to time whether the build tool
they're using supports it or not
On Tue, Apr 7, 2009 at 3:23 PM, David Cournapeau wrote:
> On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
> wrote:
>
>>
>> What is involved in building python extensions ? Can you please explain ?
>
> Not much: at the core, a python extension is nothing more than a
> dynamically loaded librar
On Wed, Apr 8, 2009 at 2:24 AM, Heikki Toivonen
wrote:
> David Cournapeau wrote:
>> The hard (or rather time consuming) work is to do everything else that
>> distutils does related to the packaging. That's where scons/waf are
>> more interesting than cmake IMO, because you can "easily" give up thi
>> I don't know thing one about cmake, but if it's good for the goose
>> (building Python proper) would it be good for the gander (building
>> extensions)?
Antoine> African or European?
I was thinking Canadian...
Skip
___
Python-Dev ma
Greg Ewing wrote:
Steve Holden wrote:
Isn't it strange how nobody every complained about the significance of
whitespace in makefiles: only the fact that leading tabs were required
rather than just-any-old whitespace.
Make doesn't care how *much* whitespace there
is, though, only whether it's
On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
wrote:
>
> What is involved in building python extensions ? Can you please explain ?
Not much: at the core, a python extension is nothing more than a
dynamically loaded library + a couple of options. One choice is
whether to take options from d
On Tue, Apr 7, 2009 at 2:14 PM, wrote:
>
>Ondrej> ... while scons and other Python solutions imho encourage to
>Ondrej> write full Python programs, which imho is a disadvantage for the
>Ondrej> build system, as then every build system is nonstandard.
I fully agree here.
> Hmmm... L
On Tue, Apr 7, 2009 at 9:14 PM, wrote:
>
> Ondrej> ... while scons and other Python solutions imho encourage to
> Ondrej> write full Python programs, which imho is a disadvantage for the
> Ondrej> build system, as then every build system is nonstandard.
>
> Hmmm... Like distutils setup
pobox.com> writes:
>
> I don't know thing one about cmake, but if it's good for the goose (building
> Python proper) would it be good for the gander (building extensions)?
African or European?
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Ondrej> ... while scons and other Python solutions imho encourage to
Ondrej> write full Python programs, which imho is a disadvantage for the
Ondrej> build system, as then every build system is nonstandard.
Hmmm... Like distutils setup scripts?
I don't know thing one about cmake, bu
Steve Holden wrote:
Isn't it strange how nobody every complained about the significance of
whitespace in makefiles: only the fact that leading tabs were required
rather than just-any-old whitespace.
Make doesn't care how *much* whitespace there
is, though, only whether it's there or not. If
it
Ondrej Certik wrote:
> Hi,
>
> On Sun, Mar 29, 2009 at 10:21 AM, Jeffrey Yasskin wrote:
>> I've heard some good things about cmake — LLVM, googletest, and Boost
>> are all looking at switching to it — so I wanted to see if we could
>> simplify our autoconf+makefile system by using it. The biggest
David Cournapeau wrote:
> On Mon, Mar 30, 2009 at 2:59 AM, Antoine Pitrou
> wrote:
...
>
> Waf is definitely faster than scons - something like one order of
> magnitude. I am yet very familiar with waf, but I like what I saw -
> the architecture is much nicer than scons (waf core amount of code
Hi,
On Sun, Mar 29, 2009 at 10:21 AM, Jeffrey Yasskin wrote:
> I've heard some good things about cmake — LLVM, googletest, and Boost
> are all looking at switching to it — so I wanted to see if we could
> simplify our autoconf+makefile system by using it. The biggest wins I
> see from going to cm
On Mon, Mar 30, 2009 at 8:49 PM, Christian Heimes wrote:
> David Cournapeau wrote:
>> On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf
>> wrote:
>>> Can you please explain ? What is "those" ?
>>
>> Everything in Lib. On windows, I believe this is done through project
>> files, but on linux at
David Cournapeau wrote:
> On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf
> wrote:
>> Can you please explain ? What is "those" ?
>
> Everything in Lib. On windows, I believe this is done through project
> files, but on linux at least, and I guess on most other OS, those are
> handled by distu
Hallo Alexander!
Alexander Neundorf wrote:
> This of course depends on the definition of "as good as" ;-)
> Well, I have met Windows-only developers which use CMake because it is
> able to generate project files for different versions of Visual
> Studio, and praise it for that.
So far I haven't h
On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf
wrote:
>
> Can you please explain ? What is "those" ?
Everything in Lib. On windows, I believe this is done through project
files, but on linux at least, and I guess on most other OS, those are
handled by distutils. I guess the lack of autoconf
On Mon, Mar 30, 2009 at 8:04 PM, David Cournapeau wrote:
> On Tue, Mar 31, 2009 at 2:37 AM, Alexander Neundorf
> wrote:
...
>> Not sure I understand.
>> Having a project which builds (shared) libraries and executables which
>> use them (and which maybe have to be executed later on during the
>> b
On Tue, Mar 31, 2009 at 2:37 AM, Alexander Neundorf
wrote:
> On Mon, Mar 30, 2009 at 12:09 AM, Neil Hodgson wrote:
> ...
>> while so I can't remember the details. The current Python project
>> files are hierarchical, building several DLLs and an EXE and I think
>> this was outside the scope of th
On Mon, Mar 30, 2009 at 12:09 AM, Neil Hodgson wrote:
...
> while so I can't remember the details. The current Python project
> files are hierarchical, building several DLLs and an EXE and I think
> this was outside the scope of the tools I looked at.
Not sure I understand.
Having a project which
Hi,
On Mon, Mar 30, 2009 at 1:22 AM, Christian Heimes wrote:
> Jeffrey Yasskin wrote:
>
>> 1. It can autogenerate the Visual Studio project files instead of
>> needing them to be maintained separately
>
> I'm familiar with the Unix and the Windows build system. More than a
> year ago I went to
-On [20090329 19:21], Jeffrey Yasskin (jyass...@gmail.com) wrote:
>However, Brett Cannon and I talked, and we think this is surmountable.
>First, nearly every desktop system comes with a Python interpreter, which
>would avoid the bootstrap for ordinary development.
This is quite a major assumption
Jeffrey Yasskin wrote:
> 1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately
I'm familiar with the Unix and the Windows build system. More than a
year ago I went to a great deal of work to migrate the Windows builds
from VS 7.1 to VS 9.0.
Jeffrey Yasskin:
> 1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately
I have looked at a couple of build tools (scons was probably one)
that generate Visual Studio project files in the past and they
produced fairly poor project files,
On Sun, Mar 29, 2009 at 1:14 PM, David Cournapeau wrote:
> About cmake: I haven't looked at it recently, but I have a bit of hard
> time believing python requires more from a build system than KDE. The
> lack of autoheader is not accurate, if
> only because kde projects have it:
>
> http://www.cma
On Mon, Mar 30, 2009 at 3:18 AM, Antoine Pitrou wrote:
> What are the compilation requirements for cmake itself? Does it only need a
> standard C compiler and library, or are there other dependencies?
CMake is written in C++. IIRC, that's the only dependency.
cheers,
David
David Cournapeau gmail.com> writes:
>
> I would think the bootstrap problem to be much more significant. I
> don't find the argument "many desktop have already python" very
> convincing - what if you can't install it, for example ?
I agree. I had to build Python once on a corporate AIX box witho
On Mon, Mar 30, 2009 at 2:59 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin gmail.com> writes:
>>
>> The other popular configure+make replacement is scons.
>
> I can only give uninformed information (!) here, but in one company I worked
> with, the main project decided to switch from scons to cmake
Jeffrey Yasskin gmail.com> writes:
>
> The other popular configure+make replacement is scons.
I can only give uninformed information (!) here, but in one company I worked
with, the main project decided to switch from scons to cmake due to some huge
performance problems in scons. This was in 2005
Nice report! Thanks!
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. K
I've heard some good things about cmake — LLVM, googletest, and Boost
are all looking at switching to it — so I wanted to see if we could
simplify our autoconf+makefile system by using it. The biggest wins I
see from going to cmake are:
1. It can autogenerate the Visual Studio project files instea
43 matches
Mail list logo
