Ok - so I know we've had a bit of back and forth over this issue. So I'm
only going to argue for configure in the repo one more time. Here is my
argument:
It's what users expect. When I checkout a repo I always expect to be able
to do:
./configure
make
make install (optionally)
I thought that one of the reasons we were moving to Automake was to get
closer to what users expect (in the "make install" arena). Further,
libMesh has always been usable through a simple:
./configure
make
So it's what _our_ users expect.
There was some back and forth about whether or not we needed "configure" in
the repo or only in our distributed tarballs. Here are my thoughts:
1. Most people using libMesh use the repo... and it's something we
actively encourage. It should work just like a release.
2. A lot of projects put configure in the repo.
To show #2, here is a list of free software on Savannah (
http://savannah.gnu.org/ ) the GNU software repository that both has
configure in the repo (just random clicking around, there is a bunch of
junk in there):
ACM: http://cvs.savannah.gnu.org/viewvc/acm/acm/
Combine: http://cvs.savannah.gnu.org/viewvc/combine/combine/
Crust: http://cvs.savannah.gnu.org/viewvc/crust/crust/
Emacs: http://cvs.savannah.gnu.org/viewvc/emacs/emacs/
Epiwm: http://cvs.savannah.gnu.org/viewvc/epiwm/epiwm/
Grub: http://cvs.savannah.gnu.org/viewvc/grub/grub2/
(got tired of looking through crappy projects)
There are definitely a lot of projects that don't put configure in the repo
as well... BUT I believe that since our users mainly use our repo version
(which is not the norm for a lot of software) our repo should come in a
form that is amenable to our users.
Finally... one last thing:
libMesh needs to be able to compile on MANY different kinds of machines.
This is unique to HPC software like this. We have to have it "just work"
on all kinds of crazy architectures that we have no control over. For that
reason, I think that we shouldn't rely on Autoconf on those machines... and
should have a checked in version of configure that we know is good.
Ok - I've said my peace.
Derek
On Sat, Nov 17, 2012 at 6:49 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> What Id like to try first is beefing up bootstrap to install the newer
> versions for you. It does that now if the autotools are missing, so it just
> needs to be updated to go the version checking too.
>
> I'll get to that after kids soccer today. In the meantime you can cut and
> paste the relevant lines from bootstrap and it will install a local set of
> the autotools in your development tree.
>
> -Ben
>
>
> On Nov 16, 2012, at 10:56 PM, "Derek Gaston" <fried...@gmail.com> wrote:
>
> So, did we decide we were going to check in "configure" or what?
>
> Here's what happens with bootstrap on my Lion MacBook Pro:
>
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal -I m4
> configure.ac:56: error: Autoconf version 2.62 or higher is required
> m4/prefix_config.m4:209: AX_PREFIX_CONFIG_H is expanded from...
> configure.ac:56: the top level
> autom4te: /usr/bin/gm4 failed with exit status: 63
> aclocal: /usr/bin/autom4te failed with exit status: 63
> autoreconf: aclocal failed with exit status: 63
>
>
>
>
> On Fri, Nov 16, 2012 at 9:18 PM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> Merge is complete and trunk is back in business. I'll be working on
>> updating documentation for updating the build system over the next few days.
>>
>> In the meantime please contact me before you get too frustrated with
>> automake - it is usually easy to do something if you do it the 'automake
>> way.'
>>
>> -Ben
>>
>>
>>
>> On Nov 16, 2012, at 3:40 PM, "Kirk, Benjamin (JSC-EG311)" <
>> benjamin.kir...@nasa.gov> wrote:
>>
>> > As of r6384, I am merging the automake branch back in to trunk.
>> >
>> > The old build system (trunk at r6383) exists as
>> >
>> >
>> https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0
>> >
>> > Unfortunately, the underlying SVN database on sourceforge is old and
>> crusty, so am having to do some svnadmin hackery to update it to a recent
>> format so I can reintegrate. I will send another email when this completes
>> and trunk is back in business.
>> >
>> > Thanks,
>> >
>> > -Ben
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Monitor your physical, virtual and cloud infrastructure from a single
>> > web console. Get in-depth insight into apps, servers, databases, vmware,
>> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> > Pricing starts from $795 for 25 servers or applications!
>> > http://p.sf.net/sfu/zoho_dev2dev_nov
>> > _______________________________________________
>> > Libmesh-devel mailing list
>> > Libmesh-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Libmesh-devel mailing list
>> Libmesh-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>
>
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
