From: Benjamin R. <ben...@ou...> - 2013-01-07 16:57:41
|
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 |
From: Thomas K. <th...@kl...> - 2013-01-07 17:11:59
|
On 7 January 2013 16:57, Benjamin Root <ben...@ou...> 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 |
From: Benjamin R. <ben...@ou...> - 2013-01-07 17:24:48
|
On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...>wrote: > On 7 January 2013 16:57, Benjamin Root <ben...@ou...> 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 |
From: Eric F. <ef...@ha...> - 2013-01-07 17:29:16
|
On 2013/01/07 7:24 AM, Benjamin Root wrote: > > > On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl... > <mailto:th...@kl...>> wrote: > > On 7 January 2013 16:57, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> 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, 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 > > Ben Root |
From: Michiel de H. <mjl...@ya...> - 2013-01-08 01:50:10
|
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...@ou...> wrote: From: Benjamin Root <ben...@ou...> Subject: Re: [matplotlib-devel] autoconf+python To: "Thomas Kluyver" <th...@kl...> Cc: "matplotlib development list" <mat...@li...> Date: Monday, January 7, 2013, 12:24 PM On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...> wrote: On 7 January 2013 16:57, Benjamin Root <ben...@ou...> 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Michael D. <md...@st...> - 2013-01-07 17:30:40
|
On 01/07/2013 12:24 PM, Benjamin Root wrote: > > > On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl... > <mailto:th...@kl...>> wrote: > > On 7 January 2013 16:57, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> 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. 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 |
From: Eric F. <ef...@ha...> - 2013-01-07 17:39:05
|
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 |
From: Matěj T. <mat...@gm...> - 2013-01-07 20:43:53
|
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 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 |
From: Michael D. <md...@st...> - 2013-01-07 21:41:45
|
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? > Very little point, admittedly. But I still encounter sysadmins who insist on "./configure; make; make install" to work sometimes. Mike |