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

[Christopher Allan Webber]

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 "bootstrap.sh".  This
> normally would be for the devs only.  It's just used to regenerate
> configure from configure.ac, which normally the user wouldn't have to
> do.  However, inside configure.ac, 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 bootstrap.sh is run, the default
> prefix becomes the current working directory.  
>
> So, if we make the default prefix in configure.ac `pwd`, the user would
> have to do:
>
> $ ./bootstrap.sh
> $ ./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 setup.py and setup.py.in?  One thing I
>> like about not having setup.py be setup.py.in 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 setup.py.in,
>> but maybe while there's no modifications being made, it would be best
>> for it to just be setup.py.
>
> There's not much difference.  You can certainly just go back to having
> the old setup.py.  Normally in pyconfigure, the idea is that you do the
> standard Autoconf thing of defining the project name, bug email and
> version number in configure.ac, and then these values are substituted
> into setup.py during configuration.  That way the only place to make
> changes (say, version bumps) is in configure.ac.  So that's all that's
> happening here.  Well, except for the version number, since you guys
> have that in mediagoblin/_version.py.  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 Makefile.in 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 setup.py and then add it to PyPI, that dist will
> contain a normal setup.py file as well.  As of now, the setup.py script
> knows nothing about the pyconfigure files, so setup.py.in won't be in
> there, nor will configure or Makefile.in.  So I think the solution is
> for a dev to run configure to generate setup.py 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 setup.py 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 setup.py.in, 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 bootstrap.sh (`make distclean`)

Great!

>> 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!