On Fri, 2015-10-16 at 12:06 +0000, Michael Ferguson wrote: > […] > > You and I had a discussion about how we might be able to support > 'make install' after the April release. I think that is still > a valuable thing to do, but we didn't get to it this release.
Indeed, but now I am using Git master (trying to get tooled up to assist with the Python stuff), I feel more directly associated with this as a problem! > > […] > > libchplmalloc.a is a library available for opt-in use only, > so it's not strictly necessary to install. > > libchpl.a will be used in the linking step when you actually > compile a .chpl program with the chpl compiler. I'd be surprised > if you have a working compiler without it... It seems that I have been fortunate. "make clean" does not remove the two lib*.a files. Although I moved the chpl executable and cleaned, it uses CHPL_HOME to find things (modules source for example) and it seems the libchpl.a. Fortuitously the Debian gcc 5.2 and the Fedora gcc 5.1 appear to be able to mutually interwork for this. > 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. > * 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.) > * 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. Library configurations for Chapel seem more complex that the general set up of Debian, Fedora and OSX allows for so some extra complexity is needed. Accumulating all appropriate configurations for the platform seems eminently reasonable. > > 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 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… -- 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
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
