In general you guys are talking about "features" though: when in my
estimation the "core" capability of the development cycle is broken. I
don't think that maintaining "nice" features is worth it at the cost of
hurting the main development cycle
(build->fix->build->fix->add_file->build->fix->test).
I would rather fix the core development cycle - then backfill features
based on priority (install > check > dist > out-of-tree, etc.). We
completely chucked a sane development flow for the sake of a few features
that are rarely actually used.
As for symlinking: that's done so that we can maintain code organization -
and allow for the "libmesh/" prefix for #includes (namespacing the header
file names essentially).
Derek
On Thu, Aug 30, 2018 at 2:50 PM Paul T. Bauman <ptbau...@gmail.com> wrote:
> This all got started while I was lecturing for my two undergrad classes,
> so I'm going to piggy back on Roy's response to start and then reply to
> some others since history was getting trimmed in some replies.
>
> On Thu, Aug 30, 2018 at 12:28 PM Roy Stogner <royst...@ices.utexas.edu>
> wrote:
>
>>
>> On Thu, 30 Aug 2018, Derek Gaston wrote:
>>
>> > After all of these years: I still dislike the Automake build system
>> > in libMesh.
>>
>> So do I.
>>
>
> All build systems suck. As Ben pointed out, one advantage with autotools
> is not having to build the build system. (CMake, SCons, etc.)
>
>
>> > I still can't believe that we threw out a perfectly
>> > decent build system and saddled ourselves with this thing.
>>
>
> Decent, but feature incomplete.
>
>
>> > In hindsight: do you guys TRULY think it was worth it?
>>
>> For install/dist/distcheck targets, and out-of-source builds? Yeah.
>>
>
> I'll add 'check' target as well, but emphatically yes on all counts.
> Especially check, install, and out-of-source builds.
>
>
>> > All I'm trying to do right now is add ONE damn header file - and I
>> > can't seem to find the magic script / sauce to get everything
>> > updated. I ran include/rebuild_include_HEADERS.sh ... nope. I ran
>> > bootstrap... still nope. Oh! Now I remember... I need to run
>> > include/libmesh/rebuild_makefile.sh... NOPE!
>>
>
> https://github.com/libMesh/libmesh/wiki/Adding-or-removing-source-files
>
> Should we put one magic add_files.sh at the top level?
>>
>> But the two include shell scripts should have done it... that's always
>> worked for me. I guess I usually manually bootstrap afterwards too,
>> but in my experience automake is smart enough to rerun itself if it
>> sees Makefile.am newer than Makefile.in.
>>
>
> But I do agree this seems like a needless hassle to symlink the header
> files. Were we just trying to preserve some transition between svn and git
> or something? Why not just `git mv` the headers and get rid of the need for
> symlinking. I'm sure I'm missing something, but I don't remember what it is.
>
>
>> > Ok - 100% serious here. If I redo the libMesh build system so that
>> > it's autoconf and make based again - would you guys consider
>> > switching to it?
>>
>> Consider? Yes. Anticipate agreeing to with such a high probability
>> that the work would be worth your time? No.
>>
>
> Pretty much this. I don't think it's worth the time because none of the
> features we have with automake I'm willing to give up.
>
>
>> Except... if you're going full Focus on creating a new build system,
>> presumably you'd want to put it in MOOSE too...
>>
>> 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)
>
>
> I disagree, I think dist and distcheck are important. Also `make check`.
>
>
>> it would be totally worth the switch
>> from my point of view. You'd still have to convince others though.
>>
>> (It's not really graft if I let my decisions get swayed for code
>> rather than money, right? ...)
>> ---
>>
>
>> Roy------------------------------------------------------------------------------
>
>
>> 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
>>
>
------------------------------------------------------------------------------
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
