Just to chime in on a couple of aspects of this mail:
* 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).
* 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).
* 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.
-Brad
On Fri, 16 Oct 2015, Michael Ferguson wrote:
Hi Russel -
On 10/16/15, 4:46 AM, "Russel Winder" <[email protected]> wrote:
I am wondering if I am missing something regarding installing Chapel.
Most systems use SCons, CMake, Tup, Autotools, Waf, or recently Bazel
is getting some interest, for build. These build systems offer an
installation capability so that you build, install, clean and can build
and install for different architectures from the same filestore.
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.
It might be worth noting that JetBrains CLion currently assumes you are
using CMake though I am trying to get them to support SCons as well.
Eclipse assumes you are using Autotools but using SConsolidator can be
used very nicely with SCons. Netbeans assumes you are using Autotools,
but it can be hacked to use SCons insead. Which IDEs are Chapel
developers using? (Emacs is an acceptable answer, VIM is not :-),
though neither of these are really IDEs.
Currently the Make build infrastructure seems to assume you will build
in the filestore and run from that filestore. This is not entirely
workable for people who have filestores shared across architectures (in
my case Debian Sid, Fedora Rawhide and OSX). Currently, I build, copy
chpl to ~/Built/bin and clean for the three architectures. Which is
annoying. SCons and CMake could sort this out very quickly.
Am I missing something by not capturing libchpl.a and libchplmalloc.a?
(they get made but appear unused.) Are there other compilation products
that should be installed for a full installation?
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...
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
* 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.
* 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/
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.
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).
Cheers,
-michael
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
