On Thu, Aug 30, 2018 at 3:20 PM Derek Gaston <fried...@gmail.com> wrote:
> On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman <ptbau...@gmail.com> wrote:
>
>> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston <fried...@gmail.com> wrote:
>>
>>> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner <royst...@ices.utexas.edu>
>>>
>>
>> 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.
>
That shouldn't happen. I'm betting that you made another change along side
or it's an artifact of the symlinking bits (which needs to be fixed). The
only time configure ever needs to be rerun is if you change your
configuration you or you change how you configure your build (configure.ac).
When I add new files and hit `make` in my build tree, automake reruns and
then proceeds with the build, regardless of .h or .C file additions. Even
changing Makefile.am does not need a 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.
>
Sure, because there is a lot of dependency in those files, but I claim most
of the libMesh changes happen much farther downstream of that. In fact,
rarely do I have to recompile more than a handful of libMesh files.
> 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.
>
I perish to think how many needless complete rebuilds of the stack was
required for a small change.
> 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!
>
Again, in-source builds just worked for me literally just now. `configure;
make` or just `make`. I'm not sure what else you're doing your script.
> 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?
>
No, usually two or three (mostly devel, then opt, but then sometimes dbg
with stdcxx-debug enabled for really detailed tracing). But sometimes
different versions of PETSc with the previous variations. But yes, in those
cases, usually only a handful of files get rebuilt. Of course if you change
something in mesh_base.h you're basically rebuilding the whole library, but
most of the time we are touching something much less "central" (solvers,
elements, FEMSystem).
> 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.
>
No. Triggering a reconfigure is very rare for me.
> 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.
>
Huh? There are plenty of times already where devel passed and dbg didn't.
Running these configurations in tandem always is critical.
>
>
>> 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.
>
How? It literally just did it and it worked fine. What is in your script
besides `make install`?
> 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.
>
It shows adding a file should be streamlined. It's hyperbole to extrapolate
that to saying the build system is broken when literally every feature of
the current build system is exercised and is passing on CI.
> 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
>
I agree, but that's easy to enable configure option for (which you'd need
to do in any other build system anyway).
> -2. In editor building broken (in multiple ways)
>
This may be valid. I don't do in editor building.
> -3. Pain to add any single new file (especially headers)
>
This was number 1 under negatives, no double-counting allowed.
> -4. Thousands of Makefiles
>
(A handful) That you never need to look at, touch, or otherwise modify?
This is not a valid criticism.
> -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)
>
I believe this is only because of the symlinking which I agree should go
away.
> -5. Creating new examples is a HUGE pain
>
It is annoying to get it to `make install` properly (and not hugely
annoying it is mostly automated). Creating a new example is easy.
> -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.
>
Huh? I'm not sure how it gets any easier then literally running the script
that is installed along side the example.
------------------------------------------------------------------------------
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
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
