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
