Re: [Libmesh-devel] Still Really Dislike Automake

[Derek G. <fri...@gm...>]

On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman <ptb...@gm...> wrote:

> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston <fri...@gm...> wrote:
>
>> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner <roy...@ic...>
>>
>
> I strongly disagree with this statement. It is *vital* for development. On
> my CIVET server I have multiple builds with different
> options/configurations and I would have to reconfigure and rebuild the
> entire bloody tree for one commit change instead of going to the build
> directory and hitting `make` and only building the files and dependencies
> for each configuration. It is a *HUGE* time saver. Let alone on my own box.
>

I sincerely doubt it - even the tiniest change (like adding a header file
that is only included in one .C file triggers a complete reconfigure.  Any
tiny change to mesh / equation_systems / etc. creates a whole rebuild.  I'd
love to see statistics on how much this saves you.


> On the other end, users don't need it at all because they are usually just
>> happy to get something to build for _one_ environment configuration (and
>> many never, ever want to rebuild after that).  I seriously think it's just
>> not worth it.
>>
>
> *Users* may not care, but it is *vital* for developers. And I'm a
> developer, not just a user.
>

How many developers are using it?  I know that I _never_ do so "vital" is a
bit too far.  We developed libMesh for MANY years without it as well.  In
addition: MOOSE has never had it and I've only ever heard one person
complain (Roy).

Most of the MOOSE developers (besides myself and John) simply run the MOOSE
script that we have to rebuild libMesh because they can't even be bothered
to deal with it manually.  Before Automake that script never even existed!


> Now, "install" I can see a need for.  I don't personally care about it -
>> but the arguments are convincing enough.  It's something that both
>> developers and users might want to use.
>>
>> In my mind "install" also obviates a lot of the need for out-of-tree
>> builds: if you need multiple configurations built - just install them to
>> different places.
>>
>
> From a user point of view, sure. From a developer point of view, this is
> simply false. I want my different build configurations sitting around so I
> only have to rebuild what's necessary for that configuration without having
> to reconfigure and rebuild *all* files, not just dependencies for each
> configuration.
>

Again - I simply don't see it.  Even in my own workflow I trigger complete
rebuilds of most of libMesh fairly often.  Do you really make one tiny
change then go rebuild 5 configurations every time?  I would think that you
would work with one configuration for quite a while - then go try others.
At the point you make many edits and want to try another configuration
you're going to end up rebuilding most (if not all) of the tree - in
addition you're probably going to trigger a re-configure.

Also - with CI this is less important - work in one configuration... let CI
handle the others.  Only build a "non-standard" configuration when CI shows
that you've botched it.


> If out-of-tree-builds are a requirement: I would like them off by default.
>>
>
> I strongly disagree. In fact, I do not understand what the problem is here
> regarding in vs. out-of-source builds. I just did an in-source build of
> libMesh master and it worked fine (I recall we made sure that this worked
> for you guys). If you're having to do any maintenance for in-source builds
> I don't know what because it's not on the libMesh side.
>

It "kinda" works - I have to maintain my own "install" script that gets
broken every now and again.  Also: the pathing is broken on compile errors
in this mode so that Emacs can't figure out where the source files are.


> In fact, other that your original complaint about adding the file to the
> build system (for which John created a wiki page so we can all remember),
> I've not seen any other actual issue other that just being unhappy with
> Autotools.
>

Literally every time I have to do development in libMesh I run into the
friction.  The fact that we have to have a wiki page about how to add a new
file just shows that it's broken.


> Positives:
>
> 1. Out-of-source builds just work. In-source builds work. You can do
> either. And this requires no maintenance for files compiled into the
> library (there is a little work for new examples, but it's mostly
> automated).
> 2. make install just works. For both in-source and out-of-source builds.
> 3. make check just works. For both in-source and out-of-source builds.
> 4. make dist just works for preparing release tar balls.
> 5. make distcheck just works for checking said release tar balls will
> actually configure/make/make check/make install.
> 6. It will work on any system that supports make and a shell script
> (configure).
>
> 1,2,3,4,5,6 are vital, non-negotiable features for me.
>
> Negatives:
>
> 1. The automation of adding a new file should be more straight forward
> (which I think it would be if we just did away with the symlinks, but I've
> forgotten why we needed that in the first place, so maybe we can't).
> 2. ... What else?
>

-1. Rebuilding/linking of all the small executables every time
-2. In editor building broken (in multiple ways)
-3. Pain to add any single new file (especially headers)
-4. Thousands of Makefiles
-4b. Makefiles in include directories cause in-editor building to get hung
up (I have to switch to a .C file and build from there)
-5. Creating new examples is a HUGE pain
-6. Trying to use an example to try out a new feature (or editing an
existing example) also sucks.  You have to use pretty funky command-lines
just to get a single executable re-run.