-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Add documentation on build systems #5015
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
080ce4c
719eccb
ae99a9e
ab72f1e
7fb874d
e6e0d4a
492d5f1
bc10a22
256cc2b
959131d
1b8b140
9efd47e
6f94d93
08d1596
ec880ec
30744fd
aaedf9b
92d76b9
db1f23c
a0155a0
c02e959
4a03e68
c45c8bc
99e20d9
88c2638
6d740d9
f363fd4
abe403c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,83 @@ | ||
|
|
||
| .. _build-systems: | ||
|
|
||
| ============= | ||
| Build Systems | ||
| ============= | ||
|
|
||
| Spack defines a number of classes which understand how to use common | ||
| `build systems <https://en.wikipedia.org/wiki/List_of_build_automation_software>`_ | ||
| (Makefiles, CMake, etc.). Spack package definitions can inherit these | ||
| classes in order to streamline their builds. | ||
|
|
||
| This guide provides information specific to each particular build system. | ||
| It assumes that you've read the :ref:`packaging-guide` and expands | ||
| on these ideas for each distinct build system that Spack supports: | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 1 | ||
| :caption: Make-based | ||
|
|
||
| build_systems/makefilepackage | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 1 | ||
| :caption: Make-incompatible | ||
|
|
||
| build_systems/sconspackage | ||
| build_systems/wafpackage | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 1 | ||
| :caption: Build-script generation | ||
|
|
||
| build_systems/autotoolspackage | ||
| build_systems/cmakepackage | ||
| build_systems/qmakepackage | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 1 | ||
| :caption: Language-specific | ||
|
|
||
| build_systems/octavepackage | ||
| build_systems/perlpackage | ||
| build_systems/pythonpackage | ||
| build_systems/rpackage | ||
| build_systems/rubypackage | ||
|
|
||
| .. toctree:: | ||
| :maxdepth: 1 | ||
| :caption: Other | ||
|
|
||
| build_systems/cudapackage | ||
| build_systems/intelpackage | ||
| build_systems/custompackage | ||
|
|
||
| For reference, the :py:mod:`Build System API docs <spack.build_systems>` | ||
| provide a list of build systems and methods/attributes that can be | ||
| overridden. If you are curious about the implementation of a particular | ||
| build system, you can view the source code by running: | ||
|
|
||
| .. code-block:: console | ||
|
|
||
| $ spack edit --build-system autotools | ||
|
|
||
|
|
||
| This will open up the ``AutotoolsPackage`` definition in your favorite | ||
| editor. In addition, if you are working with a less common build system | ||
| like QMake, SCons, or Waf, it may be useful to see examples of other | ||
| packages. You can quickly find examples by running: | ||
|
|
||
| .. code-block:: console | ||
|
|
||
| $ cd var/spack/repos/builtin/packages | ||
| $ grep -l QMakePackage */package.py | ||
|
|
||
|
|
||
| You can then view these packages with ``spack edit``. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or with
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. $ spack edit foois fewer characters than $ less ~/spack/var/spack/repos/builtin/packages/foo/package.pyso I went with the former.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again... people need to know where the files really are if they aren't going to see Spack as magic. @tgamblin I would also LOVE to shorten some of these needlessly long paths in Spack. I understand the rationale of mirroring a Unix filesystem. But I don't see how it helps us, or where it is useful. What I DO see is unnecessarily long paths, along with having to remember which bits of Spack end up in /var vs /opt vs/ share vs /lib. It all seems so arbitrary and NOT user friendly. At the very least, I would like symlink shortcuts to commonly used directories. I asked for this before and the idea was rejected. But I still want them, and I still add them routinely to my branches. |
||
|
|
||
| This guide is intended to supplement the | ||
| :py:mod:`Build System API docs <spack.build_systems>` with examples of | ||
| how to override commonly used methods. It also provides rules of thumb | ||
| and suggestions for package developers who are unfamiliar with a | ||
| particular build system. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really dubious on the value of this command. It's more work for me to remember the special
spack editcommand than the general approach of finding the file in the Spack directory. Why don't we just tell users where the build system.pyfiles are?In addition... I edit remotely, so
spack editwill never work for me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not reopen old wounds. This was settled on in #2865. You might not find it useful, but I probably used it hundreds of times while writing these docs. I don't know if I could survive without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please just provide appropriate alternatives. Tell people where the file is located in case they want to edit it themselves, give URLs to GItHub, etc.