bug-pyconfigure
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-pyconfigure] PyConfigure


From: Arne Babenhauserheide
Subject: Re: [Bug-pyconfigure] PyConfigure
Date: Tue, 05 Mar 2013 01:00:42 +0100
User-agent: KMail/4.10 (Linux/3.6.11-gentoo; KDE/4.10.0; x86_64; ; )

Hi Brandon,

Am Montag, 4. März 2013, 23:58:25 schrieb Brandon Invergo:

> Thanks for the great feedback! Life has denied me the one or two solid
> weekend days that I need to wrap up the next pyconfigure release

I know that feeling ;)

> > - Why is there code for virtualenv in the autoconf.ac? Should that not
> >   be included by default, so every python project which uses
> >   pyconfigure can be installed with virtualenv? (that goes along the
> >   lines of having a unified way to install)
>
> The virtualenv-related macros are in configure.ac so that the generated
> configure script gives the user the option of whether or not to install
> to a virtualenv. But, since I agree that it should be included in most
> configure scripts, it is not commented out in the sample
> configure.ac. So, in my mind, that is "included by default"...unless you
> meant something else?

What I meant is, that since it should always be available, it should not have 
to be in the autoconf.ac: It could just be included in the m4 macros by default.

Differently put: Every Python build should include it without having to add 
anything to the autoconf.ac for that.

> > - Why is there no m4 macro for “maximum version” or “major version”?
> >   Having to uncomment lots of stuff in the autoconf.ac seems strange:
> >   Can’t this be shelled out to m4?
>
> I agree that version checking is still not ideal. I will work on this
> further.

Cool!

> > - Why do we have m4_include([m4/python.m4]) and
> >   AC_CONFIG_MACRO_DIR([m4])?
>
> Oops, that's cruft. I think I had problems with the AC_CONFIG_MACRO_DIR
> macro not doing what I thought it was supposed to do. I need to double
> check but I think the m4_include statement can be removed. Thanks for
> pointing it out...somehow my eyes just passed over it every time.

I only saw it because I reorganized the file and did not understand the 
difference between both: Which section should this go?

> > - Why do we need automake?
>
> At the moment, we don't, so AM initialization is commented out. I left
> it in there as a hint to devs that they can also use Automake. For some
> projects, AM's Python support will be sufficient and they'll only use
> the Autoconf macros from pyconfigure. A long-term goal of pyconfigure,
> though, is to improve its ties with Automake.

So essentially it’s in there to provide an advanced section for people who 
already know Automake and might want to use it?

> > But the m4/python.m4 could really profit from some comments explaining
> > the code - I am not used to m4 and it is kinda hard to follow. For
> > example it took me some time to figure out this:
>
> Good point. It can definitely be commented better.

I mostly missed some notes on peculiarities of the syntax of m4: Comments which 
help newcomers to the language.

Those are the comments you normally don’t need, since normally most 
contributors will know the language you use.

> > PS: Some links on the website are broken - for example the one to the
> >     help mailing list.
>
> Hmm...the links work for me. Maybe a temporary server hiccup?

I’ll recheck… the test releases break ( http://alpha.gnu.org/gnu/pyconfigure/ ) 
help-pyconfigure works again, though. Translationproject breaks 
(http://translationproject.org/domain/pyconfigure.html).

> > PPS: Here are the changes I made. You should be able to just import
> >      them as patches. They might have broken the file, though: Please
> >      double and triplecheck the result. They should apply to
> >      the restructure branch from Sun Jan 13 14:57:33 2013 +0100.
> >      (I accidently worked on that branch…)
>
> Thanks for the meaty patch! I'll edit and apply it tomorrow!

Cool!

> Thanks again for your feedback & help,

And thanks to you for creating pyconfigure!

Having a standard way of building programs is really nice, and since I’m more 
and more experimenting with multiple languages, having to remember how to build 
stuff for each of the languages actually starts to hurt…

I even added a Makefile to the directory of my PhD thesis, so that I would not 
have to remember how to tell emacs to transform the org-mode file into a PDF. I 
did not yet get to use configure, though: pyconfigure is actually the contact I 
have with creating autoconf files myself (since for all other projects they had 
been created by someone else).

Best wishes,
Arne

PS: Do you know the autotools mythbuster?
http://www.flameeyes.eu/autotools-mythbuster/
--
Konstruktive Kritik:

- http://draketo.de/licht/krude-ideen/konstruktive-kritik

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]