Hi Russel - See below:
On 10/18/15, 4:06 AM, "Russel Winder" <[email protected]> wrote: > >> If I were creating support for 'make install', I would: >> >> * install to a single directory (e.g. /opt/chapel or >> /usr/libexec/chapel) >> so that various Makefiles still work > >I am not sure what the Makefile constraint is here. > >There is no one place for installation, it is platform dependent. OSX, >Debian, Fedora,Š all have different (albeit quite similar) idiomatic >places to install things. 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. > >> * Use symbolic links/scripts to expose 'chpl' and maybe a few >> scripts to the usual places (like /usr/bin). A script could set >> CHPL_HOME. The chpl compiler tries to figure out CHPL_HOME, >> but it might need tweaking to do it right in this scenario. > >This is definitely not the way I would approach this. The chpl >executable should be in /usr/bin. With a full installation there should >be no need for a CHPL_HOME at all. Why should the Chapel compiler (and >runtime) need to have anything other than that which is installed in >known places once installed? (This is me not knowing the finer details >of the current Chapel compilation and runtime methinks.) 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. > >> * Create a 'make install' target (or script) that does this: >> - copy util/ >> - copy bin/ >> - copy lib/ (I'd install all built configs) >> - copy modules/ >> - copy runtime or maybe just runtime/include >> (for #including from generated C) >> - copy third-party/*/install/ > >There seems to be more in bin than just the compiler executable. 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. > >> >> We'd be excited to work with you to create some sh/Python scripts to >> do >> that if you're interested in contributing them. Otherwise... it will >> have to wait until we get to it. > >The problem for me is that isntallation shouldn't be a manually >constructed sh or Python script thing, it should just be a built tool >thing. CMake, SCons, Autotools, (Tup, Bazel, Waf,Š) have relatively >straightforward ways of dealing with all this. Is it right to >effectively replicate what they provide? 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? > >> I personally would be open to switching to something like CMake, but >> I don't view it as important in the near term (while supporting >> 'make install' is). And, everybody else on the project might have >> a different view. In any case, if we did use something like CMake >> it might be more complicated than usual since we view cross-compiling >> as the normal use case. Right now, I think it's nice that in one >> 'make' command you compile the chpl compiler for the "host" >> architecture and the runtime for the "target" architecture. It >> is not immediately obvious to me what that sort of thing would >> look like if we were using other build tools. (And even if I >> understood that - I'd still need a compelling reason to switch). > >Given that I prefer SCons (because I am associated with its development >I guess :-), CMake (despite the ugly build script notation) is a >popular (and used by JetBrains for CLion) evolution over Make. > >The issue of cross-compilation should not be a big deal for either >SCons or CMake (not sure about Bazel and Tup, but is quite an issue for >Autotools). > >The single biggest reason for switching is to make use of a >build/install toolchain that fits with Debian, Fedora, Arch, OpenBSD, >FreeBSD, MacPorts, Homebrew, Choclatey, etc. so that it makes it easy >to for those distributions to package with a standard workflow. As soon >as the build is a unique blend of shell scripts, there is a huge >barrier to being packaged. > >I am very close to trying to write a new build system for ChapelŠ 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. 2) If support for 'make install' is important, the fastest way to get that would be by directly making some install scripts. 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? 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? 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: 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. 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. c) actually change the build system (i.e. port over Makefiles). 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. Summing up: you haven't yet convinced me that switching to SCons (or CMake or whatever) is worth it. Cheers, -michael ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
