Skip to content
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

Documentation: Missing examples in licensed software #1140

Closed
mamelara opened this issue Jun 29, 2016 · 9 comments · Fixed by #1141
Closed

Documentation: Missing examples in licensed software #1140

mamelara opened this issue Jun 29, 2016 · 9 comments · Fixed by #1141

Comments

@mamelara
Copy link
Member

The licensed software documentation looks a bit incomplete. Some places look like they are missing images to show examples of how the global license file looks like and also another for how to use a license from another server.

Also, I think it might be helpful to add an example about a package that has multiple licenses. For example, a user at NERSC was trying to install allinea-forge and had two licenses, license.ddt and license.map. They thought that when Spack prompted them to use the global file that there would be two global files for each specified license. So it might be helpful to mention that all licenses should be placed in the global file, or something like that.

@adamjstewart
Copy link
Member

@mamelara I was the one who wrote the documentation on licensed software and who added the allinea packages. Looks like you're right, there are a couple of code blocks I added that aren't showing up. I don't actually know reStructuredText very well, so if someone can help me out I'd be glad to fix it. Is there a quick and easy way to view a .rst file locally?

Allinea is a bit complicated. Forge includes MAP and DDT. We have a single license for Forge, so I wasn't aware that you could have licenses for the individual components. They may have merged them recently? If not, we could also add separate packages for allinea-map and allinea-ddt.

@mamelara
Copy link
Member Author

According to the consultant, there are two licenses that they are using. So I'm guessing they expect two files to edit when they specify license_files = [license.ddt, license.map].

@tgamblin
Copy link
Member

@adamjstewart: if you just type make in the docs directory, and you have sphinx with py-pygments, it should build fine.

@adamjstewart
Copy link
Member

@tgamblin Did you update the docs hosted online? My change didn't seem to work.

@tgamblin
Copy link
Member

tgamblin commented Jun 30, 2016

Erm... yes... I did... and I totally didn't just do it now. 😬

@mamelara
Copy link
Member Author

@adamjstewart So will allinea-forge require two packages then? Or could we do a resource() of allinea ddt and allinea map under one allinea-forge package? Sorry to derail the thread since this is about the documentation.

@adamjstewart
Copy link
Member

@tgamblin Oh yay, it worked!

@mamelara Allinea Forge can be downloaded as a single tarball, so it should be fine as a single package. If Allinea MAP and Allinea DDT can still be downloaded individually, then they could very well have their own packages as well. Either way, if putting both licenses in the same file works, it works. I'm not sure if it's worth changing the current documentation to describe the edge case in which multiple licenses need to go in one file.

@mamelara
Copy link
Member Author

@adamjstewart fair enough. Thanks for updating the docs!

@adamjstewart
Copy link
Member

No prob, thanks for pointing out that they were broken!

sethrj added a commit to sethrj/spack that referenced this issue Nov 14, 2019
With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error spack#1140: a using-declaration may not name a constructor or destructor
        using KeywordEnumeration::KeywordEnumeration;
```
sethrj added a commit to sethrj/spack that referenced this issue Nov 14, 2019
With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error spack#1140: a using-declaration may not name a constructor or destructor
        using KeywordEnumeration::KeywordEnumeration;
```
sethrj added a commit to sethrj/spack that referenced this issue Nov 14, 2019
With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error spack#1140: a using-declaration may not name a constructor or destructor
        using KeywordEnumeration::KeywordEnumeration;
```
sethrj added a commit to sethrj/spack that referenced this issue Nov 14, 2019
With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error spack#1140: a using-declaration may not name a constructor or destructor
        using KeywordEnumeration::KeywordEnumeration;
```
adamjstewart pushed a commit that referenced this issue Nov 14, 2019
* Mark compiler/version conflict for CMake

Intel 14 lacks some C++11 features needed to compile new versions of
cmake.
```
/tmp/s3j/spack-stage/spack-stage-cmake-3.15.5-46lgp4ybhopy2p4rr66rxnew5iaddvmg/spack-src/Source/
cm_static_string_view.hxx(28): error: expected an operator
   friend static_string_view operator"" _s(const char* data, size_t
                                     ^
```

* Mark compiler/version conflict for icu4c

With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error #1140: a using-declaration may not name a constructor or destructor
        using KeywordEnumeration::KeywordEnumeration;
```

* Mark compiler/version conflict for nasm

Error installing `nasm@2.14.02%intel@14.0.4`:
```
In file included from nasmlib/crc64.c(35):
./include/nasmlib.h(116): error: expected a ";"
  fatal_func nasm_assert_failed(const char *, int, const char *);
```

* Mark compiler/version conflict for bison

Installing `bison@3.4.2%intel@14.0.4`:
```
In file included from /tmp/s3j/spack-stage/spack-stage-bison-3.4.2-
uzjszv4owvqsymjpxtxvvegfavc6k5my/spack-src/lib/quotearg.c(33):
/tmp/s3j/spack-stage/spack-stage-bison-3.4.2-uzjszv4owvqsymjpxtxvvegfavc6k5my/spack-src/lib/
xalloc.h(51): warning #303: explicit type is missing ("int" assumed)
  extern _Noreturn void xalloc_die (void);
```

* Mark compiler/version conflict for icu4c

With `icu4c@60.1%intel@16.0.4` and `icu4c@64.1%intel@16.0.4`:

```
In file included from ucurr.cpp(26):
static_unicode_sets.h(130): error #913: invalid multibyte character sequence
      {POUND_SIGN, u'£'},
                     ^
```

* Change conflict comments into messages
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants