Brad, Michael, etxal., > * Ben Albrecht is working towards supporting Chapel packages for > things like Debian, which feels spiritually related to the > 'make install' issue to me. The Mac Homebrew formula is also > somewhat related, as it's an instance of trying to make Chapel > work in a more standard directory hierarchy by subterfuge > (specifically, supplying a 'chpl' script that sets CHPL_HOME > and then calls the real 'chpl' binary, as I understand it).
The alternative might be to review what the Chapel structure should be so as to avoid hacking things. The structure has grown up to be what it is, but a review might indicate something different would be better. > * Chapel's in-place build is definitely designed to support > multiple simultaneous installations through the use of > unique-ish paths under all of its binary directories. Russel, > is the problem in your case that we're just not being specific > enough in these descriptors to distinguish between *nix flavors? > For example, I would expect a Linux and OSX install of Chapel to > be able to co-exist in a single hierarchy without problems -- > and if they don't, then something broke without us noticing. > Anyway, point being, it would be relatively simple to add some > more flavors of *nix that distinguished themselves if one wanted > them to co-exist in a single hierarchy (none of which is to say > that support for a 'make install'-ish capability is a bad one). I have had no problem with the OSX / Linux combination, that gets separated out. The issue for me is that Debian and Fedora are not distinguished by the Chapel framework, but at times they can have conflicting compilers and libraries such that compiling must be done for each separately. This is not true just now, but it was when Fedora had gcc 5.0 and Debian had gcc 4.9. > * Though I'm not familiar with most of the autotools variants that > Russel lists, I agree that cross-compilation for parallel > computers is > crucial for Chapel and, in my experience as a user anyway, seems > to > cause challenges for such systems. Specifically, anything that > wants > to probe a system by executing a program has to know how to launch > that program onto the actual compute nodes using pbs, slurm, > loadleveller or the like, and even if it knew how to do this, it > blows > up the build time significantly by adding queueing time into a > potentially shared resource into the mix. In addition, any > auto-detection by inspecting file systems is likely to either > break > down (because the compute node's file system is different) or else > be taught where to look and where not to look (in the event that > the > compute nodes and login node share a file system but have distinct > versions of software that they use). > > To that end, it always feels to me like one has the choice of > building > your own scaffolding for cross-compilation that knows about > certain > systems and architectures while being ignorant of others; or of > forcing that knowledge into someone else's tool suite. In either > case, > the auto-options don't feel like a panacea to me (though maybe > they've > evolved further than I'm aware such that the snafus above don't > apply > anymore). And generally, Chapel's gotten more kudos for having a > simple/quick/easy/extensible make architecture than lashes for > not. Autotools is not my favourite system, and it is fundamentally UNIX oriented, so given a choice I would never choose it. CMake is about making a generated Make system platform independent, and it supports cross compilation. Whether it can support probingand non-local program start I am not sure immediately, but feel it must be possible. SCons is built on Python rather than Make and so if you can do it in Python it can be done with SCons. SCons provides the build framework and if it doesn't have a particualr something you can use Python to do it. I guess I always prefer to create necessary extra bits within the highest level tool. The problem with Make and scripts is that it is not portable. As far as I am aware CMake is the most portable framework, but SCons is nicer (but I am biased). Though I guess there is the possibility that I am being a bull in someone else's china shop. -- 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
