mediagoblin-devel
[Top][All Lists]
Advanced

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

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


From: Brandon Invergo
Subject: Re: [GMG-Devel] configure/Makefile for mediagoblin
Date: Mon, 20 May 2013 00:07:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi,

I forgot to subscribe to the mailing list before. This should work now.

Christopher Allan Webber <address@hidden> writes:

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

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

> #+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 

That gets a big "oops" from me.  It's fixed now...two problems: it
should be "abs_srcdir" in the conditional and it needs line escapes to
all be on one line.  

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

Yes you're right. And I made a minor touch-up so that it properly uses
the postgres binary discovered during the configuration.

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

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

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

-- 
Brandon Invergo
http://brandon.invergo.net

Attachment: pgp2nm3RRqCqp.pgp
Description: PGP signature


reply via email to

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