[Top][All Lists]

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

Re: [GMG-Devel] configure/Makefile for mediagoblin

From: Christopher Allan Webber
Subject: Re: [GMG-Devel] configure/Makefile for mediagoblin
Date: Thu, 23 May 2013 15:51:58 -0500
User-agent: mu4e; emacs

Brandon Invergo writes:

> Ah crap.  I just wrote that without testing it (I had been using
> something else as my prefix value).  As far as I can tell, there's no
> way around the restriction to absolute paths with everything as written.
> I've found a solution though, which isn't perfect but it's not so bad.
> Inside the directory, there's a script called "".  This
> normally would be for the devs only.  It's just used to regenerate
> configure from, which normally the user wouldn't have to
> do.  However, inside, there's a macro defining the default
> prefix.  Originally I had it set to some example directory.  If I
> instead set it to `pwd`, then when is run, the default
> prefix becomes the current working directory.  
> So, if we make the default prefix in `pwd`, the user would
> have to do:
> $ ./
> $ ./configure 
> So, a two-step process now, but it does what it should.  If they want to
> install somewhere else, they can still specify a --prefix, but now it's
> not necessary.  Sound good?  The configure script is then removed from
> the repo/distribution, as it is now generated by the user.
> BTW, I also went ahead and made it use virtualenv by default, meaning
> the user no longer has to pass --with-virtualenv (instead they can
> disable it with --without-virtualenv).

Yup, that's working.  Awesome!

>> Is there any difference between and  One thing I
>> like about not having be is that if someone wants
>> to install with pip or straight out of the package with a traditional
>> python way, this works fine.  I like having the option of,
>> but maybe while there's no modifications being made, it would be best
>> for it to just be
> There's not much difference.  You can certainly just go back to having
> the old  Normally in pyconfigure, the idea is that you do the
> standard Autoconf thing of defining the project name, bug email and
> version number in, and then these values are substituted
> into during configuration.  That way the only place to make
> changes (say, version bumps) is in  So that's all that's
> happening here.  Well, except for the version number, since you guys
> have that in mediagoblin/  Though, technically we can have
> that be configured as well.
> Anyway, the main reason for doing this seemingly pointless road block is
> From the coding standards:
>   Another way for the configure script to operate is to make a link from
>   a standard name such as config.h to the proper configuration file for
>   the chosen system. If you use this technique, the distribution should
>   not contain a file named config.h. This is so that people won’t be
>   able to build the program without configuring it first.
>   Another thing that configure can do is to edit the Makefile. If you do
>   this, the distribution should not contain a file named
>   Makefile. Instead, it should include a file which contains
>   the input used for editing. Once again, this is so that people won’t
>   be able to build the program without configuring it first.
> It's been a while since I put anything on PyPI but I think that when you
> make a dist using and then add it to PyPI, that dist will
> contain a normal file as well.  As of now, the script
> knows nothing about the pyconfigure files, so won't be in
> there, nor will configure or  So I think the solution is
> for a dev to run configure to generate on his/her machine and
> then do the normal PyPI upload procedure.  I *think* that a package
> added this way to PyPI should be installable by pip/easy_install without
> a problem.  I'm curious though.

So yes, this is true.  However, one nice thing I mean by the pip install
is that pip can actually install from source, doing a full git checkout
and running develop on its own, through a single command.  Not
that I think that's a great idea, but it seems to me that there's no
real good reason given our current setup to move to, though
there might be in the future... we might as well delay it until that time.

>> There do seem like there may be some autogenerated files that could be
>> removed?  autom4te.cache and ./local/autom4te.cache probably?  I don't
>> know much about this stuff though :)
> Yes, those two files need not be included in the distribution.  In fact,
> I shouldn't have added them to the git repo :).  They can safely be removed
> after running (`make distclean`)


>> Yeah, I think we need those couple of issues I ran into resolved
>> probably, but it's looking good otherwise, and I think this will
>> simplify the install docs by a lot.
>> Thanks for all your hard work on this!
> Well, sorry I got a bit sloppy in the end there.  I thought I ironed
> everything out but I see that I left some stuff broken.  I think it
> should all be fixed now.

No reason to apologize.  Again, I appreciate the hard work.  I'm looking
forward to this landing soon!

reply via email to

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