Hi Russel - On CHPL_HOME vs a hardwired path:
> >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. I don't think it would be hard to modify the compiler build to include a hard-wired location. I think we'd generally be happy with that if CHPL_HOME continues to exist. Maybe others will chime in here to agree or disagree... > >[Š] > >> >> 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 probably get it when I 'make docs'... You could also 'make chpldoc'. > >[Š] >> >> 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. Have a look at make/platform/Makefile.linux32 which detects Ubuntu 14.04 to enable a workaround. It uses lsb_release -s -i -r which might exist on a variety of linux systems. > >> 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. Yes, exactly. I'd probably write a bash/sh script if I were doing it, but Python would be fine too. > >> 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. Actually we already have a Homebrew package. There is an old MacPorts package that we didn't make. And I think we're working on a Debian package (but getting that into Debian is another matter). Others can better describe what we are doing here... > >> 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. At this point, I'd wait to hear somebody else's viewpoint on the matter. Maybe somebody else could chime in? Also, please make a quick/short email (with a new subject in case people are ignoring this thread) if you start working on an install script so we can avoid duplicating effort. Cheers, -michael ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
