Please do not use CMake. My experiences with it in HPC production use over the past 5 years are so bad that I fear I may need a trigger warning from now on. I tolerate CMake in one and only one project that I cannot live without*, but in any case where a software project adopts CMake and I can increase my overall happiness by never use that software again, I will do so.
* libelemental.org, where I personally maintain all of the CMake toolchain files for systems that I use, because that is the only means to making CMake tolerable for users. And this maintenance effort has cost me 1-2 days out of every years dealing with CMake bugs and "features", most recently on Cray XC30 at NERSC, where it took days of back-and-forth with NERSC and a modified version of CMake to do something as simple as compile the library with static linkage. Best, Jeff On Mon, Oct 26, 2015 at 3:20 PM, Kyle Brady <[email protected]> wrote: > Hi Russel, > > We talked a little bit about build systems today. I don't think scons is > quite the right fit for what we want with our build process. I would like > to examine what CMake support would look like at some point. But, it is > not very high up on my priorities list at the moment. > > -Kyle > > On 10/23/15, 08:30, "Russel Winder" <[email protected]> wrote: > > >Michael, > > > >On Mon, 2015-10-19 at 14:59 +0000, Michael Ferguson wrote: > >[Š] > >> > >> I meant that we'd like to continue to have a CHPL_HOME directory > >> that stores the relevant files. I wasn't trying to say that the > >> CHPL_HOME > >> directory needed to be in the same place on all platforms. I view > >> this > >> approach as similar to Java's JAVA_HOME. > > > >I have no problem having a CHPL_HOME, I guess I was just trying to > >investigate if it was necessary. D has lots of source modules as well > >as executables and libraries to install and manages to avoid having to > >use an environment variable. Both have pros and cons. > > > >[Š] > >> > >> Every compiler (that I know of) needs someplace to store libraries > >> (both pre-compiled and language source code/headers). For something > >> like > >> GCC, these end up in a lib/libexec directory > >> e.g. /usr/lib/gcc/<some-arch>/<gcc-version>/. > >> > >> Certainly, we could store the files that the Chapel compiler needs > >> in a lib or libexec directory, and the chpl binary in /usr/bin. > >> In that scenario I'd still consider the lib/libexec directory to > >> be CHPL_HOME. Also, typically such a configuration would require us > >> to hard-code the lib/libexec directory path into the chpl compiler > >> binary itself. I find that distasteful (and would generally rather > >> be able to move files around and have the /usr/bin/chpl be a > >> script or symbolic link). Of course everybody has different > >> priorities > >> with this sort of thing. > > > >It is definitely not clear cut, I agree. A general observation, which I > >think is true, is that upstream folk prefer the environment variable > >approach to retain portability, whereas downstream platform packagers > >prefer being able to hardwire locations. > > > >[Š] > > > >> > >> Yes, there is chpl, chpl-ipe (interpreter), and chpldoc. > >> I would view all of these as useful tools to have available > >> on a user's PATH, at some point in the future at least. > > > >HummmŠ I am not getting chpldoc created. Definitely they should be on > >the users PATH. > > > >[Š] > >> > > >> I don't really believe this argument. Of course everyone can have > >> their own opinion, and there are merits to these build systems. > >> The script we are talking about is pretty simple. You'll have to > >> use some more specific argument than "it should work this way" > >> to convince me. Regarding replicating features, you'd have to dig > >> in a bit more for that to be a convincing argument. What specific > >> features are we replicating? Which would we need to continue > >> to replicate? Which are not working sufficiently well now? > > > >The single biggest argument for a build framework is that it is (or at > >least should be) easy to describe, as declaratively as possible, the > >project, and have the framework do all the work of deciding what need > >building/installing/uninstalling convention over configuration. The > >biggest problem I have with Make is it is not portable because it is > >too low level compared to SCons, CMake or Gradle. This especially > >matters ion the Windows vs. everything else case. What I meant about > >replication, is that the code you write for a non-framework build is > >generally replicating code that is already in the framework. > > > >However, I come from a build framework background, so I am biased and > >prejudiced. > > > >Pragmatically, install and uninstall are the only features not already > >working with the current Make-based system. Eclipse/CDT can work with > >this I suspect, but CLion really requires CMake to be able to work with > >a C and C++ project. > > > >[Š] > >> > >> Some things to point out. For some reason I feel an enumerated > >> list coming on... > > > >:-) > > > >> 1) The fastest way to solve your actual problem would be to educate > >> the Chapel make system about Linux variants (instead of just > >> "linux64" > >> the bin/lib directories could contain e.g. "linux64-fedora22" or > >> something like that. Then, you could just use one Chapel > >> directory > >> (even from a git checkout, even if you rebuild the compiler or > >> the > >> libraries regularly) across your platforms. You might find this > >> adjustment satisfying since it only involves changing a Python > >> script - princhplenv - or scripts that it calls. In particular, > >> running > >> ./util/printchplenv --compiler > >> will give the path component containing 'linux64' now for bin/, > >> and > >> ./util/printchplenv --runtime > >> will give the path component including 'linux64' now for lib. > > > >Now that all the Python scripts involved in the build work with both > >Python 2 and Python 3, this is undoubtedly the right way forward. > >Determining Debian vs. Fedora does though involve what can only be > >called a hideous hack. > > > >I'll see what I can do in terms of a pull request on printchplenv to > >deal with this. > > > >> 2) If support for 'make install' is important, the fastest way to > >> get > >> that would be by directly making some install scripts. > > > >In the current system, that could either be with a shell script in the > >Makefile, or an external shell or Python script. > > > >> 3) I don't think it would be so hard to make our build scripts mimic > >> Autotools in terms of how you run them. Wouldn't that address the > >> concern that packagers for Fedora etc. would need special > >> handling > >> for Chapel? What if we had a ./configure (even if we wrote it and > >> it interacted with the build system we already had), and we made > >> 'make install' do something reasonable? Is there a lot more that > >> these packagers would rely upon? > > > >Many projects go that route, mostly because they do not want to > >actually use Autotools, but they do want to provide the configure style > >"front end" that makes it easy to fit with "standard" workflows. In the > >end though rather than trying to pre-guess, the best bet is to > >establish a relationship with the packagers for the various platforms > >and get them to have input. For various other projects I have found > >that building a relationship with packagers makes getting upstream > >projects into distributions so much easier. Packagers don't really like > >it when upstream won't talk to them. > > > >I am not sure what people have thought before, but I would be looking > >at Debian (which thus includes Ubuntu and Mint), Fedora (and thus RHEL > >and thus Scientific Linux), Arch, MacPorts, Homebrew, OpenBSD, FreeBSD. > > > >> 4) You mentioned in your other email that you avoid Make for > >> portability > >> reasons. In fact Make is quite portable across Linux/FreeBSD/etc > >> variants > >> (which can just run GNU Make) and Mac OS X. The main exception is > >> Windows, but Chapel support for Windows requires Cygwin right now > >> (for other reasons) where it is again easy to have GNU Make. > >> Since more direct Windows support is unlikely to be a high > >> priority > >> for this effort, I don't find portability a compelling reason to > >> move > >> away from what we are doing now. Do you know of other systems > >> besides Windows where having GNU Make as a dependency is > >> problematic > >> in practice? > > > >Windows is always the problem. If there is no intention to make things > >work on Windows then that is a lot of problems with Make gone as you > >point out. I still prefer SCons, CMake, Gradle, but I am clearly not > >winning against the backdrop of the working current Make/Bash/Python > >set up :-) > > > >> 5) Rewriting the build system in CMake or SCons or whatever should > >> be > >> viewed as a big undertaking. Remember that it's not solely a > >> technical task. If you actually did that, to succeed (i.e. be the > >> normal thing everybody uses on master), you'd have to: > > > >Clearly not building at all on Windows removes much of the necessity. > > > >> a) convince the other Chapel developers that using > >> SCons/whatever > >> is better. You have do this because we'll have to work with > >> whatever build system we are using and be willing to > >> understand it. > > > >Usually the only real argument is to actually do it and show it > >working. As you say a big undertaking, not to be underestimated. > >Depending on what happens in the next few weeks, I may take it on early > >next year, or I might just say "it currently works, why fix what isn't > >broken". > > > >> b) help the other Chapel developers learn the intricacies of the > >> new build system and convince them that it is worth their > >> time to > >> learn about it. Remember that it will slow down the project > >> to > >> some extent for the rest of us to take time to learn a > >> different > >> build system, so the justification in (a) is very important. > > > >A build system should never get in the way, it should be a single > >usable command line system that can be used programmatically from IDEs. > >If you have to take a lot of time to learn the system, then there is > >something wrong. > > > >Curses, if people have difficulty learning the Make-based system I > >missed an argument that using a good build framework should remove all > >that hassle. > > > >> c) actually change the build system (i.e. port over Makefiles). > > > >Generally that is the easy bit! > > > >> > >> Personally, the places where I've been frustrated with our build > >> system have mostly been from various strange-seeming workarounds > >> for specific configurations/bugs in other software etc. These aren't > >> problems with Make itself. Don't get me wrong - Make is not a > >> super-satisfying language - but it works reasonably well for us at > >> this > >> point. We already feel empowered to write some part of the > >> configure/build system in Python if it seems useful to do so. > >> > >> It seems to me that moving to SCons would really consist of moving > >> all of the configuration-specific workaround stuff that annoys > >> me now from Makefiles to Python scripts. I'm not so sure that would > >> represent an improvement. > > > >Without actually doing it there is no possibility of proof, everything > >is just guesswork. > > > >> Summing up: you haven't yet convinced me that switching to SCons > >> (or CMake or whatever) is worth it. > > > >Clearly :-) > > > >I think the factors here are that what you have you understand and > >works (-ish), that you do not have experience of SCons or CMake, and > >that you do not build on Windows. > > > >I believe a change would improve things, but have no concrete > >measurable proof, and it is your project, I am the interloper. > > > >-- > >Russel. > >========================================================================== > >=== > >Dr Russel Winder t: +44 20 7585 2200 voip: > >sip:[email protected] > >41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > >London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > -- Jeff Hammond [email protected] http://jeffhammond.github.io/
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
