Re: [Libmesh-devel] Still Really Dislike Automake

[Paul T. B. <ptb...@gm...>]

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...>
> wrote:
>
>>
>> On Thu, 30 Aug 2018, Derek Gaston wrote:
>>
>> Should we put one magic add_files.sh at the top level?
>>
>
> I guess?  I still don't understand why these are even necessary - there
> should just be a build rule for the symlinks!
>
>
>> Except... if you're going full Focus on creating a new build system,
>> presumably you'd want to put it in MOOSE too...
>>
>
> It already _is_ in MOOSE.  Our build system is pretty awesome.  Now:
> libMesh doesn't need that level of complexity (we have added complexity for
> the cascading build capability that doesn't need to be in libMesh) - but
> the basic ideas are already there.  We even have stuff that I have no idea
> how you would do with Automake like Unity Builds.
>
>
>> And I'd really love to be able to do out-of-source builds in MOOSE
>> too.  If "autoderek" handled that (plus "make install"; I don't care
>> as much about dist/distcheck) it would be totally worth the switch
>> from my point of view.  You'd still have to convince others though.
>>
>
> This is where we start to have a problem because I just seriously don't
> see compelling enough reasons for out of tree builds.  It adds a layer of
> complexity that is annoying - and it's not really compatible with any
> "in-editor" building (like using Emacs) making it pretty not useful for
> development.
>

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.


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


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


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

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.

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?

Paul


>
> Derek
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>