I was just reading some comments from Richard Stallman on ./ when I noticed that he pointed out a useful autoconf feature that was added somewhat recently. Essentially, this feature would allow one to do a build/install of a python module using the “./configure; make install” approach, if one chooses. Maybe it should be something to consider adding to our build system?
http://www.gnu.org/software/automake/manual/html_node/Python.html
Cheers!
Ben Root
My 2 cents: I took over the maintenance of a Python project built by
autotools. The build system felt more complex than the actual application -
a fantastic world of .am files generating .in files generating Makefiles,
which themselves were packed with abstractions. I had little idea how to
change anything in the build process, and before long I ripped it out in
favour of setup.py, despite all distutils' flaws.
I'm sure that's more a question of my experience than of autotools, but I'd
think twice before adding it to a project.
Best wishes,
Thomas
On 7 January 2013 16:57, Benjamin Root <ben.root@...553...> wrote:
I was just reading some comments from Richard Stallman on ./ when I
noticed that he pointed out a useful autoconf feature that was added
somewhat recently. Essentially, this feature would allow one to do a
build/install of a python module using the "./configure; make install"
approach, if one chooses. Maybe it should be something to consider adding
to our build system?
That’s a very good point. I certainly don’t want to add significant complexity to our build system. We certainly have enough of it as-is. I was hoping that there was a way to complement our setup.py approach. In other words, “python setup.py install” would be our primary means of build/install, while allowing for “make install” as an alternative. I have yet to actually look into how this current autoconf feature would work and if that is even possible.
Ben Root
On 7 January 2013 16:57, Benjamin Root <ben.root@…553…> wrote:
I was just reading some comments from Richard Stallman on ./ when I noticed that he pointed out a useful autoconf feature that was added somewhat recently. Essentially, this feature would allow one to do a build/install of a python module using the “./configure; make install” approach, if one chooses. Maybe it should be something to consider adding to our build system?
My 2 cents: I took over the maintenance of a Python project built by autotools. The build system felt more complex than the actual application - a fantastic world of .am files generating .in files generating Makefiles, which themselves were packed with abstractions. I had little idea how to change anything in the build process, and before long I ripped it out in favour of setup.py, despite all distutils’ flaws.
I’m sure that’s more a question of my experience than of autotools, but I’d think twice before adding it to a project.
Best wishes,
Thomas
I was just reading some comments from Richard Stallman on ./
when I noticed that he pointed out a useful autoconf feature
that was added somewhat recently. Essentially, this feature
would allow one to do a build/install of a python module using
the "./configure; make install" approach, if one chooses. Maybe
it should be something to consider adding to our build system?My 2 cents: I took over the maintenance of a Python project built by
autotools. The build system felt more complex than the actual
application - a fantastic world of .am files generating .in files
generating Makefiles, which themselves were packed with
abstractions. I had little idea how to change anything in the build
process, and before long I ripped it out in favour of setup.py,
despite all distutils' flaws.I'm sure that's more a question of my experience than of autotools,
but I'd think twice before adding it to a project.Best wishes,
ThomasThat's a very good point. I certainly don't want to add significant
complexity to our build system. We certainly have enough of it as-is.
I was hoping that there was a way to complement our setup.py approach.
In other words, "python setup.py install" would be our primary means of
build/install, while allowing for "make install" as an alternative. I
have yet to actually look into how this current autoconf feature would
work and if that is even possible.
Ben,
What specific problem with our present system would you be trying to solve? I'm with Thomas on this--and there's a reason why people keep trying to develop new build systems, like cmake, scons, and waf, instead of being content with autotools.
Eric
On 2013/01/07 7:24 AM, Benjamin Root wrote:
On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <thomas@...1071... > <mailto:thomas@…1071…>> wrote:
On 7 January 2013 16:57, Benjamin Root <ben.root@...553... > <mailto:ben.root@…553…>> wrote:
Ben Root
I, also, am not too much up on the details — but I think if it’s
possible for “make install” to just call “python setup.py install”
under the hood, I’d have no objections. What I’d be wary of would
be maintaining multiple install scripts. It’s hard enough keeping
one up to date with all of the various platforms and configurations
we support. I’d be happy to replace that one with something that’s
clearly superior, however, but distutils, bad as it is, seems to be
“good enough”.
Mike
On 01/07/2013 12:24 PM, Benjamin Root
wrote:
On Mon, Jan 7, 2013 at 12:11 PM, ThomasKluyver <thomas@…1071…>
wrote:On 7 January 2013 16:57,Benjamin Root <ben.root@…553…>
wrote:I was just reading some comments from RichardStallman on ./ when I noticed that he pointed out a
useful autoconf feature that was added somewhat
recently. Essentially, this feature would allow one
to do a build/install of a python module using the
“./configure; make install” approach, if one
chooses. Maybe it should be something to consider
adding to our build system?
My 2 cents: I took over themaintenance of a Python project built by autotools. The
build system felt more complex than the actual application
- a fantastic world of .am files generating .in files
generating Makefiles, which themselves were packed with
abstractions. I had little idea how to change anything in
the build process, and before long I ripped it out in
favour of setup.py, despite all distutils’ flaws.
I'm sure that's more a question ofmy experience than of autotools, but I’d think twice
before adding it to a project.
Best wishes,
Thomas
That's a very good point. I certainly don't want to addsignificant complexity to our build system. We certainly have
enough of it as-is. I was hoping that there was a way to
complement our setup.py approach. In other words, “python
setup.py install” would be our primary means of build/install,
while allowing for “make install” as an alternative. I have
yet to actually look into how this current autoconf feature
would work and if that is even possible.
I think I would even object to that. What would be the point of it? What problem would it solve?
Eric
On 2013/01/07 7:29 AM, Michael Droettboom wrote:
I, also, am not too much up on the details --- but I think if it's
possible for "make install" to just call "python setup.py install" under
the hood, I'd have no objections.
There is one thing autotools are good at: Very easy cross-compilation
for end-users and pleasant handling of the C/C++ stuff (conditional
compilation, custom flags specified on command-line, lots of checks you
can perform before compilation, integrated testing framework etc.)
The only pitfall is that writing autotools stuff without knowing best
practices or without having full understanding of what you are doing is
going to result in endless bugreports you won't know how to solve.
If matplotlib relies heavily on C libraries, it might be beneficial,
otherwise it is probably not worth the effort for Python projects.
Matej
On Po, 2013-01-07 at 07:38 -1000, Eric Firing wrote:
On 2013/01/07 7:29 AM, Michael Droettboom wrote:
> I, also, am not too much up on the details --- but I think if it's
> possible for "make install" to just call "python setup.py install" under
> the hood, I'd have no objections.I think I would even object to that. What would be the point of it?
What problem would it solve?Eric
Very little point, admittedly. But I still encounter sysadmins who insist on "./configure; make; make install" to work sometimes.
Mike
On 01/07/2013 12:38 PM, Eric Firing wrote:
On 2013/01/07 7:29 AM, Michael Droettboom wrote:
I, also, am not too much up on the details --- but I think if it's
possible for "make install" to just call "python setup.py install" under
the hood, I'd have no objections.I think I would even object to that. What would be the point of it?
What problem would it solve?
If we use autoconf for matplotlib, we may end up using a different compiler (or compiler options) than what was used to compile Python itself. This can lead to incompatibilities that will be very hard to figure out. As far as I understand, using setup.py by default uses the same compiler and appropriate compiler/linker options as was used for Python itself.
Best,
-Michiel.
— On Mon, 1/7/13, Benjamin Root <ben.root@…553…> wrote:
From: Benjamin Root <ben.root@…553…>
Subject: Re: [matplotlib-devel] autoconf+python
To: “Thomas Kluyver” <thomas@…1124…71…>
Cc: “matplotlib development list” <matplotlib-devel@…917…ourceforge.net>
Date: Monday, January 7, 2013, 12:24 PMOn Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <thomas@…1071…> wrote:
On 7 January 2013 16:57, Benjamin Root <ben.root@…553…> wrote:
I was just reading some comments from Richard Stallman on ./ when I noticed that he pointed out a useful autoconf feature that was added somewhat recently. Essentially, this feature would allow one to do a build/install of a python module using the “./configure; make install” approach, if one chooses. Maybe it should be something to consider adding to our build system?
My 2 cents: I took over the maintenance of a Python project built by autotools. The build system felt more complex than the actual application - a fantastic world of .am files generating .in files generating Makefiles, which themselves were packed with abstractions. I had little idea how to change anything in the build process, and before long I ripped it out in favour of setup.py, despite all distutils’ flaws.
I’m sure that’s more a question of my experience than of autotools, but I’d think twice before adding it to a project.
Best wishes,
Thomas
That’s a very good point. I certainly don’t want to add significant complexity to our build system. We certainly have enough of it as-is. I was hoping that there was a way to complement our setup.py approach. In other words, “python setup.py install” would be our primary means of build/install, while allowing for “make install” as an alternative. I have yet to actually look into how this current autoconf feature would work and if that is even possible.
Ben Root
-----Inline Attachment Follows-----
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122412
-----Inline Attachment Follows-----
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel