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

[Christopher Allan Webber]

Heya,

Brandon Invergo writes:

> Hi again,
>
>> I'm not sure what the status of it is... I pinged for an update:
>>   http://issues.mediagoblin.org/ticket/536#comment:3
>>
>> I would be interested in working with someone on figuring out how well
>> this fits with current mediagoblin infrastructure.
>
> Sorry for the delay.  I finally made a draft setup with pyconfigure.
> Before I do a merge request, could someone please check it out and see
> what it's missing or what doesn't work well?
>
> https://gitorious.org/mediagoblin/mediagoblin-pyconfigure/trees/configure
>

Cool... I actually think the link you meant was:

  https://gitorious.org/~brandoninvergo/mediagoblin/mediagoblin-pyconfigure

No need to do a merge request; see recent mails to this list about merge
requests (they are being phased out).  Posting the link to the branch to
the ticket is just fine, and I've done so and moved it to code review
state.


> So, once you get the code, cd into the directory and run:
>
> $ ./configure --with-virtualenv --prefix=.
>

Sounds promising!  However, this does not work for me:

cwebber@earlgrey:~/devel/mediagoblin-pyconfigure$ ./configure --with-virtualenv 
--prefix=.
configure: error: expected an absolute directory name for --prefix: .

In the meanwhile, I did:

  ./configure --with-virtualenv --prefix=`pwd`

though I think it would be ideal if we could do the --prefix=. as you
have above.

> "--prefix" should point to the location where the site will be served
> from.  Following the documentation, you would check out the mediagoblin
> code and put it directly where you will be serving the site from, so in
> this case, you set "--prefix=.". You could potentially have the code
> anywhere and set --prefix to something else, i.e. say the code is at
> ~/Projects/mediagoblin, from there you would run
>
> $ ./configure --with-virtualenv --prefix=/srv/mg.example.org/mediagoblin
>
> Then run either 
>
> $ make develop
>

Great.  I'm looking at the generated makefile; I appreciate that it
tries to do the right thing around --system-site-packages.

It looks like it works, as in it sets everything up correctly, which is
great!  It's failing on the last bit (after everything is set up though)
here:

#+BEGIN_SRC sh
endif
        if [[ $(DESTDIR)$(prefix) != $(srcdir) ]]; then
                $(INSTALL_DATA) $(srcdir)/Makefile $(DESTDIR)$(prefix)/Makefile
                $(INSTALL_DATA) $(srcdir)/lazycelery.sh 
$(DESTDIR)$(prefix)/lazycelery.sh
                $(INSTALL_DATA) $(srcdir)/lazyserver.sh 
$(DESTDIR)$(prefix)/lazyserver.sh
        fi
#+END_SRC

It's failing with the following error:

Finished processing dependencies for mediagoblin==0.4.0.dev
if [[ /home/cwebber/devel/mediagoblin-pyconfigure != . ]]; then
/bin/bash: -c: line 1: syntax error: unexpected end of file
make: *** [develop] Error 1

Note two things:

 - Since I did the `pwd` this isn't matching, though really there's no
   need for it not to... maybe it should try to expand . to an absolute
   path?
 - For some reason it's failing othewise also, though I can't figure out
   why.

> or 
>
> $ make install
>
> That should install all the necessary files to the
> /srv/mg.example.org/mediagoblin directory, including a copy of the
> Makefile.  The documentation specifies "develop" (i.e. setup.py develop)
> but I made an "install" target as well.  You should then be able to run
> any of the following commands either from the source directory or from
> the site directory.
>
> To set up PostgreSQL:
>
> $ make postgres
>

It looks like it's "make postgresql".  But impressive!

> To update (setup.py develop --upgrade & updatedb):
>
> $ make update
>
> There are also some targets for documentation, making a distribution,
> etc. 

Awesome... I have some ideas on how we might expand these and use this
to make updating MediaGoblin easier for users.

> I opted to make the Makefile a wrapper around setup.py. But note that
> setup.py has been moved to setup.py.in.  Upon running "configure",
> setup.py will be created.  This is in line with the GNU coding
> standards. 

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.

> Have a look through configure.ac and Makefile.in, since that's primarily
> where the changes were made.  I kept a lot of the comments from the
> default pyconfigure files so that you have an idea of what's going on.
> Notably, you'll see in configure.ac that all of the prerequisites are
> tested for.  From now on, be sure to update the version number contained
> in configure.ac.

Okay.. I don't know configure or make very well, but these seem fairly
small and readable, which I appreciate.

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 :)

> So anyway, like I said, please check it out and let me know how it can
> be improved!
>
> Cheers,
> Brandon

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!

 - Chris