If there are no plans to change to autotools (or better, modern build system
*cough* SCons *cough*) then consider this a feature request for "make
install" behavior for the reasons listed in my previous email.
On Sat, Jul 3, 2010 at 9:58 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> wrote:
> Ok. No one tells me how it works on all kinds of platforms, but I guess the
> fact they don't say it doesn't work is a good thing!
>
>
> On Jul 3, 2010, at 9:54 AM, "Derek Gaston" <[email protected]> wrote:
>
> This is one huge vote against this whole thing.
>
> Why are we even doing this? The current build system works great. If
> we're going to change it then let's move to a better, newer system.
>
> A LOT of user code is dependent on the libmesh build system. Whatever we
> move to it still needs to generate the current makefile.export or something
> similar.
>
> Have to list every source file individually? Is this still 1982? I don't
> understand how that can be the case. Can we write a script that
> autogenerates that list?
>
> Don't fix it if it aint broke. Libmesh is the easiest scientific package
> to compile right now... Everyone always talks about how it just works on all
> kinds of platforms.... Let's not mess that up.
>
> Derek
>
> Sent from my iPhone
>
> On Jul 3, 2010, at 6:57 AM, "Paul T. Bauman" < <[email protected]>
> [email protected]> wrote:
>
> On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311)
> <<[email protected]><[email protected]>
> [email protected]> wrote:
>
>> OK, so I used to hate automake out of ignorance, now I hate it out of
>> experience.
>>
> Agreed on all counts.
>
>
>>
>> Still, that said, it does have some benefits. I think we could take
>> advantage of it as a parallel-path build system for a trial period.
>> Before
>> I invest any effort in porting, however, I'd like to solicit your
>> thoughts.
>>
>> Mine:
>>
>> pros:
>> (1) its what people expect
>>
> Yes.
>
>> (2) make install
>>
> This is a big deal I think. This would enable having multiple installs of
> libMesh sitting around with one source tree and enable developers to monkey
> in the code with out breaking the installs. This is a big big plus to me.
>
>> (3) make dist
>>
> This is handy.
>
>> (4) it 'does the right thing' for shared libraries and makes
>> platform-agnostic makefies
>>
> Usually. I hate libtool more than autoconf and automake combined. I
> currently have a problem in my own code where it doesn't do the right thing
> for "make check" on Mac, but does on Linux.
>
>>
>> cons:
>> (1) manually add source files
>>
> This is actually not as heinous as I originally thought it would be. The
> leg work up front is tedious and should be done with beer in hand, but
> adding new source files is pretty quick, especially if you organize things.
>
> What is infuriating is handling what gets "installed" and what goes into
> "dist". For example, you have to list all .h files to be installed. I
> would've liked them to assume that if you want a shared library installed,
> you'll want to install all the headers used to build it. Alas, you have to
> specify manually. Similarly for dist. Very annoying. Or maybe I'm still too
> green with autotools.
>
> (2) verbosity hides compiler warnings, unless using really new versions
>> with
>> silent rules
>>
> I haven't explored too much - are there rules to make things less verbose?
> I too am annoyed by my 30 line long compile lines that hide everything when
> I do make -j 3.
>
> I volunteer to help with a lot of the leg work on this if it's decided to
> move forward with it.
>
> Paul
>
>
> ------------------------------------------------------------------------------
> This <http://SF.net>SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit <http://sprint.com/first>sprint.com/first --
> <http://p.sf.net/sfu/sprint-com-first><http://p.sf.net/sfu/sprint-com-first>
> http://p.sf.net/sfu/sprint-com-first
>
> _______________________________________________
> Libmesh-devel mailing list
> <[email protected]>[email protected]
> <https://lists.sourceforge.net/lists/listinfo/libmesh-devel>
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
> <ATT00001..txt>
>
> <ATT00002..txt>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
