On Fri, Aug 31, 2018 at 7:23 AM Derek Gaston <fried...@gmail.com> wrote:
> On Thu, Aug 30, 2018 at 6:28 PM Paul T. Bauman <ptbau...@gmail.com> 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 will look into this because this is super annoying. It will
>> not remove the need to run the script to add the file names to the build
>> system though.
>>
>
> Building these with configure is (arguably) worse. I don't want to have
> to run configure when I add a new header!
>
We're already running configure, I was just suggesting it could be easy to
move step away from the run script using already existing bits in autotools.
> No - these should be in the _Makefile_. You can write a generic rule that
> will generate them.
>
For just doing the symlinks, this could possibly be done. One would need to
look at how the dependencies are setup and who's using the symlinks in
their build vs. the actual source files. We cannot get around adding the
files names to the Makefile.am files. That should not trigger a
reconfigure, just a run of automake before the build proceeds; if a
reconfigure is triggered, we should try and fix that.
> Why is everyone so afraid of actually writing Make? I don't get it.
>
No one in this thread is afraid of writing make. But we do not have time to
rewrite a new build system from scratch that contains all the features we
want. And that's effectively what you're proposing. If you do have the time
and your efforts achieve my goals, Roy's goals, Ben's goals, your goals,
and it's more streamlined for everyone, than that would be fucking awesome.
I think it will be a huge time investment and what Roy and I are pointing
out is that we're not willing to compromise on out-of-source builds, and
install and check make targets in our builds. (I still think dist and
distcheck targets are necessary, but it sounds like I'll get outvoted). So
we would hate to see you sink several weeks into something that you're
happy with and doesn't have these capabilities and it ultimately doesn't
get adopted.
And there need not be an all-or-nothing to this. If there are things we can
try and fix now with the current system, we should do that. I will try and
find time re: reconfiguring-that-shouldn't-be-needed. If it's easy to write
make targets to build only one method, we could probably do that
(Makefile.am files are ultimately just Makefiles, so we can add our own
make rules); I'm not sure how easy it would be to modify the check and
install targets to operate on a single METHOD, but if you don't need those,
it might be possible.
Here is the bit of Makefile I created for doing something similar for MOOSE:
>
> https://github.com/idaholab/moose/blob/devel/framework/moose.mk#L60-L93
>
> It works for every header file - in every directory and symlinks them all
> into another directory.
>
> It NEVER has to change: no matter if you add header files, add
> directories, add sub-directories, rename directories... ANYTHING. It is
> absolutely full-proof because it puts the symlink generation into the same
> dependency resolution stream as everything else in the Makefile.
>
> This is what I'm talking about - create a good, generic Make-based build
> system and it should never have to change (unless you actually want to
> change the behavior of the build system itself).
>
This would be feasible for the build process, but almost certainly
impossible for adding examples, make install, make check, etc. So part of
whatever build system would need to be touched for these.
>
> 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
