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.
>
>
>> 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.
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 :-)
>
>
>> 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.
> -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.
> -2. In editor building broken (in multiple ways)
>>
>
> This may be valid. I don't do in editor building.
>
That makes sense! :-)
> -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.
> -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"
> -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!
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?
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?
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.
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?
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
