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
