From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-07-03 01:54:57
|
OK, so I used to hate automake out of ignorance, now I hate it out of experience. 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 (2) make install (3) make dist (4) it 'does the right thing' for shared libraries and makes platform-agnostic makefies cons: (1) manually add source files (2) verbosity hides compiler warnings, unless using really new versions with silent rules |
From: Paul T. B. <ptb...@gm...> - 2010-07-03 12:57:53
|
On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> 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 |
From: Derek G. <fri...@gm...> - 2010-07-03 14:54:10
|
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" <ptb...@gm...> wrote: On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> 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 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 Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-07-03 14:58:22
|
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" <fri...@gm...<mailto:fri...@gm...>> 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" <<mailto:ptb...@gm...>ptb...@gm...<mailto:ptb...@gm...>> wrote: On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) <<mailto:ben...@na...><mailto:ben...@na...>ben...@na...<mailto:ben...@na...>> 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<http://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://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 <mailto:Lib...@li...>Lib...@li...<mailto:Lib...@li...> <https://lists.sourceforge.net/lists/listinfo/libmesh-devel>https://lists.sourceforge.net/lists/listinfo/libmesh-devel <ATT00001..txt> <ATT00002..txt> |
From: Paul T. B. <ptb...@gm...> - 2010-07-03 15:00:55
|
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) < ben...@na...> 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" <fri...@gm...> 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" < <ptb...@gm...> > ptb...@gm...> wrote: > > On Fri, Jul 2, 2010 at 8:54 PM, Kirk, Benjamin (JSC-EG311) <<ben...@na...><ben...@na...> > ben...@na...> 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 > <Lib...@li...>Lib...@li... > <https://lists.sourceforge.net/lists/listinfo/libmesh-devel> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > <ATT00001..txt> > > <ATT00002..txt> > > |
From: John P. <pet...@cf...> - 2010-07-03 15:24:28
|
On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman <ptb...@gm...> wrote: > 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. This would be my vote (add make install to existing build system) as well. I think this is the biggest 'pro' you listed that we are currently lacking... I don't know what make dist is and don't we already pretty much do the right thing for shared libraries on linux/mac os? -- John |
From: Roy S. <roy...@ic...> - 2010-07-03 16:54:05
|
On Sat, 3 Jul 2010, John Peterson wrote: > On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman <ptb...@gm...> wrote: > 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. > > This would be my vote (add make install to existing build system) as well. I kind of liked that "we move to automake, but someone other than me does all the work" option. But just adding a "make install" target would be easier. > I think this is the biggest 'pro' you listed that we are currently > lacking... For me the only unlisted pro of automake is that IDEs understand it... but that's just based on my failed attempt to import libMesh into eclipse (or was it some KDE thing?) years ago; it may be outdated info. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-20 21:41:22
|
> On Sat, 3 Jul 2010, John Peterson wrote: > >> On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman <ptb...@gm...> wrote: >> 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. >> >> This would be my vote (add make install to existing build system) as well. > > I kind of liked that "we move to automake, but someone other than me > does all the work" option. > > But just adding a "make install" target would be easier. > >> I think this is the biggest 'pro' you listed that we are currently >> lacking... > > For me the only unlisted pro of automake is that IDEs understand it... > but that's just based on my failed attempt to import libMesh into > eclipse (or was it some KDE thing?) years ago; it may be outdated > info. Consider this thread revived. In addition to not writing a make install in the previous 18 months, there is another missing feature which I've recently had an increased need for: proper VPATH builds. After a few years of learning autotools for FIN-S I have a proper appreciation for it... Many ages ago we successfully introduced the METHOD concept as a way for managing multiple build versions, but there is a serious Achilles heel - Make.common must always be the same. So it is easy to build opt, dbg, devel on the same platform, but forget managing a build for multiple systems out of the same $LIBMESH_DIR. For me at least this would be a very nice feature - I currently maintain three libmesh installations on different machines that can all see the same filesystem because they all have different Make.common's. Derek made an argument agains autotools at one point because our current system 'just works' - but I think that is more because it is properly maintained. It is easy to write a poorly constructed autotools installation, but a well constructed one will work as well as what we have. Plus, moving to a proper libtool installation will help in the future with shared libraries on multiple platforms (yeah, looking at you OSX). Anyone have a serious change of heart in the past 18 months and would leave the project if we did this? If not I might start a branch and see how bad it gets... -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-02-20 21:47:39
|
On Mon, Feb 20, 2012 at 3:41 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Anyone have a serious change of heart in the past 18 months and would leave > the project if we did this? If not I might start a branch and see how bad > it gets... > If anything, the past 18 months have made me want this more. I'm still up for providing a lot of code to help out here (and I've done it a few times at this point for other projects). Just say the word. |
From: Boyce G. <gri...@ci...> - 2012-02-20 22:53:05
|
On 2/20/12 4:41 PM, Kirk, Benjamin (JSC-EG311) wrote: > Plus, moving to a proper libtool installation will help in the future with > shared libraries on multiple platforms (yeah, looking at you OSX). Several years ago, I spent a lot of time trying to get libtool+autoconf+automake to work on the Cray XT4 at PSC. I ultimately had to give up on libtool --- it was taking too much time to figure out how to rig it to work. Just autoconf+automake seemed to work fine on that system, however. Hopefully things are better now, but it might be a good idea to verify that libtool works on whatever "exotic" systems you have access to before going all in... -- Boyce |
From: Paul T. B. <ptb...@gm...> - 2012-02-20 23:15:27
|
On Mon, Feb 20, 2012 at 4:30 PM, Boyce Griffith <gri...@ci...>wrote: > Hopefully things are better now, but it might be a good idea to verify > that libtool works on whatever "exotic" systems you have access to > before going all in... I completely sympathize about troubles with libtool. However, one aspect of this I would push for is that "make dist" should just work so that you can ship a tarball to the system you want and that tarball should be independent of autotools. Of course, this would require having an up-to-date autotools package sitting around somewhere... |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-21 19:08:19
|
> On 2/20/12 4:41 PM, Kirk, Benjamin (JSC-EG311) wrote: >> Plus, moving to a proper libtool installation will help in the future with >> shared libraries on multiple platforms (yeah, looking at you OSX). > > Several years ago, I spent a lot of time trying to get > libtool+autoconf+automake to work on the Cray XT4 at PSC. I ultimately > had to give up on libtool --- it was taking too much time to figure out > how to rig it to work. Just autoconf+automake seemed to work fine on > that system, however. > > Hopefully things are better now, but it might be a good idea to verify > that libtool works on whatever "exotic" systems you have access to > before going all in... Thanks for the heads up. I googled the symptoms you describe and it seems that on the XT4 you link with different libraries based on the type of node you were on... and maybe libtool was snarfing the compile line on one machine and executing it on another where some libraries were different. In any case - it is nice to be aware of that issue. I believe we could easily fall back to a no-libtool build option in that case, at the expense of only getting static libs on that platform. We had a similar issue ages ago on the power 4 (or was it 3??) that forced us to use static libraries. -Ben |
From: Derek G. <fri...@gm...> - 2012-02-22 02:47:38
|
On Tue, Feb 21, 2012 at 12:07 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Thanks for the heads up. I googled the symptoms you describe and it seems > that on the XT4 you link with different libraries based on the type of node > you were on... and maybe libtool was snarfing the compile line on one > machine and executing it on another where some libraries were different. > > In any case - it is nice to be aware of that issue. I believe we could > easily fall back to a no-libtool build option in that case, at the expense > of only getting static libs on that platform. We had a similar issue ages > ago on the power 4 (or was it 3??) that forced us to use static libraries. > On the Cray machines you have to build static binaries anyway. At least on Jaguar at Oak Ridge that's the way that it was. I believe that the OS they run on the nodes is actually incapable of loading shared libraries. This is a big bummer because there was a no way to use TBB.... Derek |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-22 03:27:16
|
>> In any case - it is nice to be aware of that issue. I believe we could >> easily fall back to a no-libtool build option in that case, at the expense >> of only getting static libs on that platform. We had a similar issue ages >> ago on the power 4 (or was it 3??) that forced us to use static libraries. >> > On the Cray machines you have to build static binaries anyway. At least on > Jaguar at Oak Ridge that's the way that it was. I believe that the OS they > run on the nodes is actually incapable of loading shared libraries. This is a > big bummer because there was a no way to use TBB.... Now that threading is in the C++ standard I wonder how long TBB gets reimplemented as a header-only library, or better yet - pulled in to the standard library. Of course, I wonder if Cray will ever actually implement native threading in C++ or just implement the keywords and run them on one thread, calling it good... |
From: Derek G. <fri...@gm...> - 2012-02-21 16:40:40
|
Even just thinking about this topic makes me a bit ill. We have a fairly intricate build system built on top of libMesh's current build system that is in use by nearly 100 developers spread across all the national labs and several universities. We have put a _ton_ of work into this system, but it heavily relies on the Makefiles libMesh generates. It is a "cascading" build system where dependent libraries are automatically rebuilt as needed (it's necessary in our system where we have multiple "layers" with each layer being a separate library). I don't want to be "that guy" but once again I have to say: it works pretty damn well the way it is. We never have any trouble compiling on even the most esoteric supercomputers. I can see two benefits of changing it: 1. Builds for multiple systems in the same tree. - Firstly, we could do this now, very easily, by just providing a different prefix / suffix for the different machines (just like we do with dbg, opt, devel) - Secondly, this just doesn't happen very often. We have a similar situation here at INL with multiple supercomputers and shared home directories, the way that we deal with this issue is by tying multiple libMesh checkouts together through a centralized Git repo in our home directory. In this way we can push and pull between different libMesh's for different machines. But… how often do we do that? Almost never. Generally we're working with _one_ machine at the moment. It's very rare to actually need to build modified versions of libMesh (which is where this would be useful… if it's just vanilla libMesh then I don't see the problem with having different directories for each machine) on multiple machines. I'm not saying it doesn't happen, but out of the millions of libMesh compiles a year by all of it's users, that has got to be close to 0.01% of the time. BTW: We just use a directory structure to manage this stuff like so ~/projectes/machine1/libMesh, ~/projectes/machine2/libMesh, etc… And for actual installed versions of libMesh on the machines those are handled through the "module" systems on those machines. 2. "make dist". This is becoming more important for us. We are going to have to start doing binary distributions pretty soon. If changing build systems would allow us to easily do that… then I might be for it. How hard would this be to do with our current build system? Derek On Feb 20, 2012, at 2:41 PM, Kirk, Benjamin (JSC-EG311) wrote: >> On Sat, 3 Jul 2010, John Peterson wrote: >> >>> On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman <ptb...@gm...> wrote: >>> 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. >>> >>> This would be my vote (add make install to existing build system) as well. >> >> I kind of liked that "we move to automake, but someone other than me >> does all the work" option. >> >> But just adding a "make install" target would be easier. >> >>> I think this is the biggest 'pro' you listed that we are currently >>> lacking... >> >> For me the only unlisted pro of automake is that IDEs understand it... >> but that's just based on my failed attempt to import libMesh into >> eclipse (or was it some KDE thing?) years ago; it may be outdated >> info. > > Consider this thread revived. In addition to not writing a make install in > the previous 18 months, there is another missing feature which I've recently > had an increased need for: proper VPATH builds. After a few years of > learning autotools for FIN-S I have a proper appreciation for it... > > Many ages ago we successfully introduced the METHOD concept as a way for > managing multiple build versions, but there is a serious Achilles heel - > Make.common must always be the same. So it is easy to build opt, dbg, devel > on the same platform, but forget managing a build for multiple systems out > of the same $LIBMESH_DIR. > > For me at least this would be a very nice feature - I currently maintain > three libmesh installations on different machines that can all see the same > filesystem because they all have different Make.common's. > > Derek made an argument agains autotools at one point because our current > system 'just works' - but I think that is more because it is properly > maintained. It is easy to write a poorly constructed autotools > installation, but a well constructed one will work as well as what we have. > > Plus, moving to a proper libtool installation will help in the future with > shared libraries on multiple platforms (yeah, looking at you OSX). > > Anyone have a serious change of heart in the past 18 months and would leave > the project if we did this? If not I might start a branch and see how bad > it gets... > > -Ben > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2012-02-21 17:13:00
|
On Tue, 21 Feb 2012, Derek Gaston wrote: > it heavily relies on the Makefiles libMesh generates. Makefiles, plural? I expect there's quite a few people (myself included) who have application code which relies on our Make.common. But getting automake to export a backwards compatible (or even a practically identical) Make.common wouldn't be too hard. In this case I'd still love to see us move to automake. But are you also relying on our Makefile.const, or much worse: our Makefile? That would be much more precarious; automake throws a ton of crap into its generated Makefiles and there'd be no telling what might conflict with an external system. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-21 17:17:18
|
> Even just thinking about this topic makes me a bit ill. We have a fairly > intricate build system built on top of libMesh's current build system that is > in use by nearly 100 developers spread across all the national labs and > several universities. We have put a _ton_ of work into this system, but it > heavily relies on the Makefiles libMesh generates. It is a "cascading" build > system where dependent libraries are automatically rebuilt as needed (it's > necessary in our system where we have multiple "layers" with each layer being > a separate library). For external applications I am not sure there necessarily will be any change at all. I'm trying to keep the same Make.common - which is all you need, no? So what I am trying to do is get automake integrated to build libMesh and the contributed packages. To test this I am going to try and leave the examples makefiles unchanged and get that to work. There are two types of application linkages in my mind: (1) those that include our Makefile.common, and (2) those that use libmesh-config I think if we do this right we can support both without change > I can see two benefits of changing it: > > 1. Builds for multiple systems in the same tree. > - Firstly, we could do this now, very easily, by just providing a different > prefix / suffix for the different machines (just like we do with dbg, opt, > devel) We will definitely get this - this is one of my main motivations > 2. "make dist". This is becoming more important for us. We are going to > have to start doing binary distributions pretty soon. If changing build > systems would allow us to easily do thatŠ then I might be for it. How hard > would this be to do with our current build system? In the automake context 'make dist' will package up a release-able tarball which itself is independent of the autotools Are you talking about binary distributions of libMesh? What we will get is the typical 'make install' that packagers are expecting, and from there it would be much easier to support RPMs or other binary packages. A benefit of the automake baggage is that it implements the GNU development standards which makes using the package much more predictable, and easier for bundlers. -Ben |
From: Derek G. <fri...@gm...> - 2012-02-21 17:20:00
|
Yes, we just use Make.common. However, our users also do build libMesh quite often and are used to the METHOD options… are those going to be maintained? I'm coming around to the idea. Derek On Feb 21, 2012, at 10:17 AM, Kirk, Benjamin (JSC-EG311) wrote: > >> Even just thinking about this topic makes me a bit ill. We have a fairly >> intricate build system built on top of libMesh's current build system that is >> in use by nearly 100 developers spread across all the national labs and >> several universities. We have put a _ton_ of work into this system, but it >> heavily relies on the Makefiles libMesh generates. It is a "cascading" build >> system where dependent libraries are automatically rebuilt as needed (it's >> necessary in our system where we have multiple "layers" with each layer being >> a separate library). > > For external applications I am not sure there necessarily will be any change > at all. I'm trying to keep the same Make.common - which is all you need, no? > > So what I am trying to do is get automake integrated to build libMesh and > the contributed packages. > > To test this I am going to try and leave the examples makefiles unchanged > and get that to work. There are two types of application linkages in my > mind: > > (1) those that include our Makefile.common, and > (2) those that use libmesh-config > > I think if we do this right we can support both without change > >> I can see two benefits of changing it: >> >> 1. Builds for multiple systems in the same tree. >> - Firstly, we could do this now, very easily, by just providing a different >> prefix / suffix for the different machines (just like we do with dbg, opt, >> devel) > > We will definitely get this - this is one of my main motivations > >> 2. "make dist". This is becoming more important for us. We are going to >> have to start doing binary distributions pretty soon. If changing build >> systems would allow us to easily do thatŠ then I might be for it. How hard >> would this be to do with our current build system? > > In the automake context 'make dist' will package up a release-able tarball > which itself is independent of the autotools > > Are you talking about binary distributions of libMesh? > > What we will get is the typical 'make install' that packagers are expecting, > and from there it would be much easier to support RPMs or other binary > packages. A benefit of the automake baggage is that it implements the GNU > development standards which makes using the package much more predictable, > and easier for bundlers. > > > -Ben > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-21 17:27:04
|
> Yes, we just use Make.common. However, our users also do build libMesh quite > often and are used to the METHOD optionsŠ are those going to be maintained? Yep, the functionality will definitely be there. Right now it'll be easy to support a different METHOD in each build directory, but I think it should also be possible to support multiple METHODs in one directory. What I do in FIN-S, for example, is $ cd $FINS_ROOT/$METHOD $ ../configure $ make $ ... and then I have a ./opt, ./dbg, ./devel directory. Of course, my bash functions make it better than that: opt () { export METHOD=opt; export FINS_BUILD_DIR=$FINS_ROOT/$METHOD; export CHAR_BUILD_DIR=$CHAR_ROOT/$METHOD } I've got a branch started and will get a prototype put together pretty quick to showcase the ideas... -Ben |