On Thu, Aug 30, 2018 at 4:58 PM Derek Gaston <fried...@gmail.com> wrote:
>
>
> On Thu, Aug 30, 2018 at 4:35 PM Paul T. Bauman <ptbau...@gmail.com> wrote:
>
>> 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
>>>>> >
>>>>>
>>>>
>> 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.
>>
>
> Really? Adding one header file and rerunning the scripts caused a full
> reconfigure for me earlier.
>
I will try and find time this weekend to test this. If it causing a
reconfigure, that should be fixed.
>
>
>>
>>
>>> 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.
>>
>
> A lot of my work these days is in parallel_implementation.h and
> communicator.h.
>
Yeah, that will require rebuilding the whole tree. (BTW, thank you for your
efforts here. I'm hoping that will help out scaling quite a bit.)
>
> Your denial of how much of libMesh you have to (not!) rebuild is just as
> anecdotal as my denial of needing out-of-tree builds :-)
>
I just was pointing out that in fact there are many cases were I can
rebuild small parts of the tree with changes. I did not assert that one
never needs to rebuild the whole tree, just that it's less common.
>
>
>>
>>
>>> 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
>>
>
> Building works - but did you try to use it?
>
> You can see my "install" script I have to manually run after each build
> here:
> https://github.com/friedmud/libmesh_scripts/blob/master/libmesh_install
>
> That is the part that I have to keep up to date (it breaks once or twice a
> year - so not a huge deal).
>
> Huh? There are plenty of times already where devel passed and dbg didn't.
>> Running these configurations in tandem always is critical.
>>
>
> Sure - but _I_ don't have to run them. I let CI run them.
>
>
>> How? It literally just did it and it worked fine. What is in your script
>> besides `make install`?
>>
>
> See above
>
>
>> 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.
>>
>
> It's broken because it doesn't do the very most basic thing - allow you to
> build the software as you change it. It some things you like well
> (obviously) - but I don't understand how you can't see that it's
> non-optimal for a really normal use-case of just adding a file / directory
> / example.
>
Of course it's not optimal. There is no optimal build system. Both Roy and
I's first response to this whole thread was all the build systems suck.
This seems to suck the least of what I've seen. If there's something that
sucks less that still has all the features we want, we should try and use
that.
>
>
>> -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).
>>
>
> I would rather they were just off by default and you could do a "make
> apps" or something to build them. Or - you could go into each one and
> build it individually by typing "make" if you want that one.
>
I would be fine with this. We can do this with the current build system.
>
>
>> -2. In editor building broken (in multiple ways)
>>>
>>
>> This may be valid. I don't do in editor building.
>>
>
> That makes sense! :-)
>
Jed seems to think this works.
>
>
>> -3. Pain to add any single new file (especially headers)
>>>
>>
>> This was number 1 under negatives, no double-counting allowed.
>>
>
> This one deserves to be counted twice :-P
>
>
>> -4. Thousands of Makefiles
>>>
>>
>> (A handful) That you never need to look at, touch, or otherwise modify?
>> This is not a valid criticism.
>>
>
> It is - because diffs get generated in them a lot - and they clutter up
> the world. Only one Makefile should be necessary.
>
Even the most complex SCons builds (which is probably the best at handling
doing really complex shit with builds IMHO) has multiple SConscripts in
their trees.
-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.
>>
>
> Symlinking can't go away. We want it there for the include path
> "namespacing"
>
If we move all the headers into a libmesh folder in each include directory
in the source tree, the symlinking could go away. I don't understand why we
don't do that.
>
>
>> -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.
>>
>
> Easy? You have to manually modify Makefile.am files (last time I did it
> anyway - is there a script for that now?).
>
>
>>
>>
>>> -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.
>>
>
> Why should I have to _install_ it? I just want to build it and run it
> real quick. I'm _developing_... that has nothing to do with _installing_.
> I want to build it in place (which should produce a nice executable that's
> sitting *right there*) and then just run it!
>
For examples, I think that install is the correct focus. As a developer,
I'm making an example for users to use, not to debug code I'm writing. I
use tests for that.
> Further, I don't want to run your script - I just want to run the
> executable! What if I want to pass a different value for command-line
> parameter? I need to edit the script? Why can't I just run the executable?
>
Most (all?) examples require an input file (GetPot). The run script lowers
the barrier for users to run the example (I think) because they can run the
script right away instead of reading what needs to be fed to the example
executable. Of course you can run the executable on your own.
> I guess that gets to the crux of my issue. _installing_ should only be
> done by end users that want to put the library somewhere in their
> filesystem to be linked against by multiple applications / users. When I'm
> developing I want everything to just stay where I'm developing!
>
> I seriously don't get it. Do you actually WANT to work this way - or are
> just defending it to defend it? If you could get out-of-tree builds, and
> "make install"... without any of the hassle we have currently would
> actually not want that because you really honestly like the current system?
>
Sure, that would be fantastic. Also make check, make dist, make distcheck.
> I'm just trying to understand your motivation here. I'm honestly wanting
> to make things better - you just keep throwing up roadblocks about why
> you're fine with the status quo.
>
This whole thread started with comments from you wanting to strip out the
build system and features that we use everyday in our development and that
we consider to be essential. I'm pushing back on keeping the features that
I consider vital. Of course I would love to just drop a new file in and not
edit a fucking Makefile.am file. Or have it be easier to add an example.
I'm not aware of an existing build system that achieves all of those. If
you are willing to write one, then hell yeah. But it sure sounded like you
would rather just go with the old and take away the features we added,
which I absolutely do not want removed and, yeah, I'm going to push back on
that.
I think it would be a *significant* time investment to create such a system.
>
> Really: the current build system is _painful_. In the same way that you
> think out-of-tree-builds are "vital": I'm telling you that the current
> build system is so painful that I go WAY out of my way to avoid interacting
> with it. I do just about everything I can in a downstream app just to
> avoid having to deal with libMesh's build system.
>
> Can you just stop being defensive for a moment and think about the
> possibility that the current system isn't awesome so we can have some
> constructive dialogue about what we could do differently?
>
I never asserted ours was awesome. Merely that it sucks the least. I'd be
happy to have a different build system that was more streamlined and still
had all the features we've been discussing.
> 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
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
