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
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
