For sure, I could care less about BSD make. Just trying to point out the
rationale for why this is, and a strategy to work around.
Peace.
--
Check out the vibrant tech community on one of the world's most
engaging tech
> On Aug 30, 2018, at 11:09 AM, Roy Stogner wrote:
>
> Would it be better to try and figure out how to ameliorate the suck in
> automake, though? I don't mean to start a flame war but "the rebuild
> scripts are too confusing" is a fair criticism and if the list of
> other criticisms isn't too
On Aug 31, 2018, at 9:42 AM, Paul T. Bauman
mailto:ptbau...@gmail.com>> wrote:
Why is everyone so afraid of actually writing Make? I don't get it.
No one in this thread is afraid of writing make.
wildcards in GNU make as required by that blob are explicitly not allowed
within automake becaus
Any chance your modifications could create a build system that can coexist?
What I dislike more than automake is having to spend a good chunk of time
building the build system on a machine that’s not particularly modern…
-Ben
> On Aug 30, 2018, at 9:47 AM, Derek Gaston wrote:
>
> After all
On Fri, 31 Aug 2018, Derek Gaston wrote:
Instead of being like: "yeah - you're right, I can see that while I
like some of the things we got with the new system it does kinda
blow for some workflows... what are your ideas?"
Actual quotes from me:
I still dislike the Automake build system in
Ben: at this point I think it's pretty crazy not to just target GNU Make.
You can see from Jed's comments that that is exactly what PETSc is doing as
well (which effectively means we are too). We can pick a reasonable
minimum version and just require it.
The world moves on. We moved to C++11 (an
Derek Gaston writes:
>> It's necessary to catch errors if a symbol is removed from the library.
>> Automake/make has no way to know if changes have that effect.
>>
>
> The binaries that Roy is talking about aren't "test' binaries though.
> They're just utilities that libMesh has grown over the ye
On Fri, Aug 31, 2018 at 7:23 AM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 6:28 PM Paul T. Bauman wrote:
>
>>
>> It just occurred to me that in fact there are autoconf macros that should
>> do exactly this so configure should be able to generate the symlinks at
>> configure time and remove th
On Thu, Aug 30, 2018 at 6:28 PM Paul T. Bauman wrote:
>
> It just occurred to me that in fact there are autoconf macros that should
> do exactly this so configure should be able to generate the symlinks at
> configure time and remove the need to manually run a shell script for
> symlinking. I wil
On Thu, Aug 30, 2018 at 5:12 PM Jed Brown wrote:
> Roy Stogner writes:
> It also parallelizes better because make has a flat and complete
> dependency graph. Non-recursive make is much better.
>
Definitely! In MOOSE we actually create the entire list of of files to be
compiled across multi
As you can tell - I got pulled out to dinner last night with collaborators
and never made it back to this discussion...
Hopping back in now...
On Thu, Aug 30, 2018 at 6:00 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 5:06 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at 4:36 PM Paul T
On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
> 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
On Thu, Aug 30, 2018 at 4:58 PM Derek Gaston wrote:
>
>
> On Thu, Aug 30, 2018 at 4:35 PM Paul T. Bauman wrote:
>
>> On Thu, Aug 30, 2018 at 3:20 PM Derek Gaston wrote:
>>
>>> On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman
>>> wrote:
>>>
On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston
On Thu, Aug 30, 2018 at 5:07 PM Roy Stogner
wrote:
>
> On Thu, 30 Aug 2018, Paul T. Bauman wrote:
>
> > I would love to see how it could be sped up. The vast majority of
> > time in make install is spent in linking the library and there's no
> > getting around that.
>
> Looping over directory aft
On Thu, Aug 30, 2018 at 5:06 PM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 4:36 PM Paul T. Bauman wrote:
>
>> You guys get the blame for this one. There was insistence from MOOSE
>> developers that the bootstrapped build system be included in the master
>> tree. I was against it.
>>
>
> No wa
Roy Stogner writes:
> ... Is this something that normal people do in practice? Or is it
> just the sort of thing an Obfuscated C Code Contest winner does when
> language-only madness gets too boring and no longer calms the shakes?
It's mainly used for testing, especially if you need to use stat
On Thu, 30 Aug 2018, Jed Brown wrote:
Roy Stogner writes:
I think Derek specifically referred to the re-linking of apps whenever
the library changes, though. That's definitely more paranoid than it
needs to be.
It's necessary to catch errors if a symbol is removed from the library.
Autom
Roy Stogner writes:
> On Thu, 30 Aug 2018, Paul T. Bauman wrote:
>
>> I would love to see how it could be sped up. The vast majority of
>> time in make install is spent in linking the library and there's no
>> getting around that.
>
> Looping over directory after directory costs some time, and I'
On Thu, 30 Aug 2018, Paul T. Bauman wrote:
I would love to see how it could be sped up. The vast majority of
time in make install is spent in linking the library and there's no
getting around that.
Looping over directory after directory costs some time, and I've heard
a non-recursive automak
On Thu, Aug 30, 2018 at 4:36 PM Paul T. Bauman wrote:
> You guys get the blame for this one. There was insistence from MOOSE
> developers that the bootstrapped build system be included in the master
> tree. I was against it.
>
No way. It wasn't in the old build system - and is in the new. YOU
"Paul T. Bauman" writes:
>> No need to modify Makefiles. No need to run scripts - all done within my
>> editor with source linking to compile errors. Not currently possible.
>>
>
> Again, the building within the editor may be an issue. I'm willing to bet
> it's fixable given the number of devel
On Thu, Aug 30, 2018 at 3:50 PM Derek Gaston wrote:
> What I mean is: what if you guys could have the things you like... and we
> could also have a sane, clean system that doesn't require all the BS we
> currently have to deal with when modifying libMesh?
>
Of course I would have no problem with
On Thu, Aug 30, 2018 at 4:35 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 3:20 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman
>> wrote:
>>
>>> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
>>>
On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner >>> >
On Thu, Aug 30, 2018 at 3:44 PM Derek Gaston wrote:
> Both of you claim to use these features - fine - I believe that you do...
> but how many others?
>
> However, it's obvious that you're both passionate about these... so I will
> relent and agree that whatever build system we come up with has t
On Thu, Aug 30, 2018 at 3:28 PM Derek Gaston wrote:
>
> On Thu, Aug 30, 2018 at 3:09 PM Paul T. Bauman wrote:
>
>> On Thu, Aug 30, 2018 at 3:04 PM Paul T. Bauman
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 30, 2018 at 3:02 PM Derek Gaston wrote:
>>>
In general you guys are talking about "feature
On Thu, Aug 30, 2018 at 3:24 PM Derek Gaston wrote:
>
>
> On Thu, Aug 30, 2018 at 3:19 PM Derek Gaston wrote:
>
>>
>> -1. Rebuilding/linking of all the small executables every time
>> -2. In editor building broken (in multiple ways)
>> -3. Pain to add any single new file (especially headers)
>>
On Thu, Aug 30, 2018 at 3:20 PM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman wrote:
>
>> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
>>
>>> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
>>>
>>
>> I strongly disagree with this statement. It is *vital* for developm
Derek Gaston writes:
> Or: like I said earlier, maybe we just maintain two systems. PETSc has had
> several different build systems all at the same time because developers
> wanted different things.
It's important to note that all build systems have used the same
underlying specification. Th
On Thu, Aug 30, 2018 at 4:02 PM Jed Brown wrote:
> Derek Gaston writes:
>
> > Or: like I said earlier, maybe we just maintain two systems. PETSc has
> had
> > several different build systems all at the same time because developers
> > wanted different things.
>
> It's important to note that all
Also: let me bring up one more huge inefficiency that our users deal with:
METHODS.
Currently METHODS has to be set at configure time - and there is no way to
configure for all the METHODS you want and then only compile a particular
METHOD. This kills new MOOSE users because we want them to be ab
On Thu, 30 Aug 2018, Derek Gaston wrote:
However, it's obvious that you're both passionate about these... so
I will relent and agree that whatever build system we come up with
has to have these features. Fine.
Thanks.
Can you agree with me that the current build system adds friction
for e
What I mean is: what if you guys could have the things you like... and we
could also have a sane, clean system that doesn't require all the BS we
currently have to deal with when modifying libMesh?
It is definitely possible.
Or: like I said earlier, maybe we just maintain two systems. PETSc has
On Thu, 30 Aug 2018, Derek Gaston wrote:
I would rather fix the core development cycle - then backfill features based on priority
(install > check > dist > out-of-tree, etc.)
out-of-tree > install > check > dist.
completely chucked a sane development flow for the sake of a few features th
Both of you claim to use these features - fine - I believe that you do...
but how many others?
However, it's obvious that you're both passionate about these... so I will
relent and agree that whatever build system we come up with has to have
these features. Fine.
Can you agree with me that the c
On Thu, Aug 30, 2018 at 3:09 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 3:04 PM Paul T. Bauman wrote:
>
>>
>>
>> On Thu, Aug 30, 2018 at 3:02 PM Derek Gaston wrote:
>>
>>> In general you guys are talking about "features" though: when in my
>>> estimation the "core" capability of the dev
On Thu, Aug 30, 2018 at 3:19 PM Derek Gaston wrote:
>
> -1. Rebuilding/linking of all the small executables every time
> -2. In editor building broken (in multiple ways)
> -3. Pain to add any single new file (especially headers)
> -4. Thousands of Makefiles
> -4b. Makefiles in include directories
On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
>>
>
> I strongly disagree with this statement. It is *vital* for development. On
> my CIVET server I have multiple builds with different
On Thu, Aug 30, 2018 at 3:04 PM Paul T. Bauman wrote:
>
>
> On Thu, Aug 30, 2018 at 3:02 PM Derek Gaston wrote:
>
>> 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 "nic
On Thu, Aug 30, 2018 at 3:02 PM Derek Gaston wrote:
> 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 developm
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)
On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
> 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
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
wrote:
>
> On Thu, 30 Aug 2018, Derek Gasto
BTW: I do realize that supporting both still means that I have to deal with
Automake when modifying libMesh... but I would only have to deal with it at
the _end_ after I'm done working on something. Not _constantly_ :-)
Derek
On Thu, Aug 30, 2018 at 1:35 PM Derek Gaston wrote:
> I suppose anot
I suppose another option is to just support both build systems
indefinitely. People who want/need the stuff automake does (out of tree,
dist, install) can use automake. Everyone else that just wants to build
(98%+) can just type "make" and be happy...
Derek
On Thu, Aug 30, 2018 at 1:31 PM Derek
On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
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
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.
I still can't believe that we threw out a perfectly
decent build system and saddled ourselves with this thing.
In hindsight: do you guys TRULY think it was wo
On Thu, 30 Aug 2018, Derek Gaston wrote:
Maybe. Certainly the "configure" that we have is really good... and
that won't change. It _may_ be possible to make them coexist for a
bit.
I'd be much more open to experimentation if we can get things to
coexist; I've done that in the past with CMa
Maybe. Certainly the "configure" that we have is really good... and that
won't change. It _may_ be possible to make them coexist for a bit.
Hah - I do agree with having to build build-systems.
At any rate: I won't be working on this until after my dissertation is
complete (this fall)... so we h
48 matches
Mail list logo
