I'm attempting to link to Scribble docs provided by a third party (as opposed to core) library (specifically, data/collection), but I'm having trouble getting it to work.
With these imports:
#require[scribble/manual
scribble-abbrevs/manual
scribble/example
racket/sandbox
#for-label[(only-in racket
(foldl f:foldl)
(foldr f:foldr))
(only-in data/collection
(foldl d:foldl)]]
The following link to Racket built-in docs works:
#racketlink[f:foldl "foldl"]
But this one, to the data/collection version:
#racketlink[d:foldl "foldl"]
... results in the following error:
raco setup: WARNING: undefined tag in <pkgs>/relation/scribblings/relation.scrbl:
raco setup: (undef "--UNDEFINED:d:foldl--")
raco setup: ((lib "data/collection.rkt") foldl)
I also attempted using the #tech tag, something like:
#tech[#:doc '(lib "scribblings/data/collection/collections.scrbl")]{"foldl"}
I tried several variants of this and wasn't able to get it to work -- one thing I couldn't uncover in my scanning of the documentation, for instance here, was how the lib link works -- what exactly is the path referring to? Evidently, "scribblings" does not refer to the local scribblings folder but some kind of global documentation path. But how does one know what path to use for a particular library's documentation? This is perhaps more of a secondary question to the primary one being asked above, but any light you can shed here would be helpful.
The problem is that you only install collections-lib. This does not include its documentation which lives at collections-doc.
So either install the package collections-doc or the (meta-)package collections which will include both collections-lib and collections-doc. Then, run raco setup relation to re-render your documentation. This would suffice for your own builds.
You probably should also modify info.rkt so that other people who install your package download the desired dependencies. There are a couple of ways to set this up.
An easy way is to put collections in deps, which will require users to install the meta-package collections, hence installing both collections-lib and collections-doc.
A more difficult way is put collections-lib in deps (you did this already) and put collections-doc in build-deps. An advantage of this approach is that users won't be required to download all tools necessary for building documentation if they install your package as a binary package (which will pre-renders the documentation already).
Related
I'm getting started with Haskell and VSCode. I've forked and downloaded a repo with Haskell code. I've followed instructions for setting up a nix-shell correctly for this repo. I can successfully invoke cabal build and haskell-language-server for week 1 examples.
I've started up VSCode from within nix-shell and I can see that the language server is reporting symbol information to VSCode. For example:
However, I often find that if I try to Go To Definition VSCode reports that no definition is found:
For many of these symbols I find that if I hover my cursor over the symbol I'm shown where the symbol is defined:
Othertimes, I find that Go To Definition correctly resolves. For example, AuctionSchema on this line resolves correctly, while AuctionSchema on this line does not.
Why does Go To Definition only sometimes work? Is there a way to fix this?
I use emacs within NixOS, and I find that definitions are only found when they’re within the project I’m working on. Sometimes if I’m in src and the definition is in lib it won’t find it either. I just assumed that Haskell Language Server cannot use Cabal or Hpack to find definitions, but only follows types within the directory branch the current source resides. Yep, that’s annoying, but it seems to be what’s currently on offer.
I read the official documentation, some examples on github and on atomicorp . But I am still confused!
Should have to make 2 specs? One to build the tools and another one for a metapackage?
If yes why atomicscorp's spec file seem to be a mix of spec and the meta-spec files ?
Moreover with rpmlint 1.10 on metapackage seem to contracdict the documentation and examples. I have this error:
scl-runtime-package-without-%scl_files
SCL runtime package must contain %scl_files in %files section.
And examples used %scl_files statement into the runtime part (line 172)
Any help is welcome
Thanks
Should have to make 2 specs? One to build the tools and another one for a metapackage?
YES.
One for the metapackage
One for each package, which will require the metapackage-build in the buildroot.
I am trying to add some python libraries to my custom image.
So far, I successfully added some libraries.
Some others, like sqlalchemy, was requiring some python internal module named “dummy_threading” and thus producing some error output stating "No module named ‘dummy_threading’ ".
I found out you can solve this issue by adding ‘python-threading’ to the image.
Unfortunately, I came across a similar issue with the ‘python-requests’ library, which cannot be imported throwing 'No module named ‘cgi’ ".
cgi.py seems to be a python internal module, much like ‘dummy_threading’, but I can’t find a way to include it to my image.
I already tried to add 'python-cgi' with no success.
Does anyone have a solution to this ?
Lucas
Additionnal info:
Yocto 1.7 (I cannot upgrade it to the newest)
Python 2.7.3
Despite poky already contains maybe all what you need regarding python, as you mention, there are some internal parts of python which are provided in a different way.
A good idea to find out how to get what you miss is to inspect the manifest files. Such files can be found in your layers (basically poky and openembedded-core). For example, in poky is located in:
poky/meta/recipes-devtools/python/python-x.y-manifest.inc
If I check inside mine I can see:
FILES_${PN}-netserver="${libdir}/python2.7/cgi.* ${libdir}/python2.7/*HTTPServer.* ${libdir}/python2.7/SocketServer.* "
Notice the cgi. and the FILES_${PN}-netserver.
Finally that would mean that the package you need is actually "python-netserver".
I am currently using yocto for building an embedded linux image for TI AM335x (I am using hob, since I find it more comfortable than using command-line).
I start using the recipe for building 'core-image-base' and here is the selection of packages which are included:
Now I would like to exclude the package alsa-utils-1.0.28-r0 from build, since it has some problems compiling for my target and I really do not need it... so, as far as I can understand, I have to remove all the dependencies which brought alsa-utils in (that is: alsa-state and packagegroup-base, looking at following screenshot):
So I move to Package groups tab and I remove packagegroup-base and then I remove alsa-state and alsa-utils from the Included recipes:
Now it seems that alsa-utils is there no more... but if I try to build the image, this is the result:
Why? Who is still bringing-in alsa-utils? What am I doing wrong? Is there a way (even command-line) to know why a package is brought-in by yocto?
Use
bitbake -g alsa-utils -u depexp
to display a dependency tree you should be able to see who's depending on it.
See the openembedded wiki.
so what I'm trying to do is utilize a simple Qt application IN eclipse without using the eclipse QT plugin by linking the required libraries through the GCC C++ Linker. However, I have been unable to locate the exact name of the library to use, or which libraries will be necessary. I've located the path of the Qt library my application seems to be accessing, but I continue to get an error when building that just says "-lqt" doesn't exist/can't find, etc.
The reason I'm doing this is because I'm building a simple game in OGRE for a project at the uni and wanted to use a Qt application for the GUI. Well, I didn't necessarily want too, but our professor wishes us to do so. Please don't suggest that I simply embed an Ogre widgit into my Qt application as this isn't an opti
Any ideas?
Thanks <3
Well, if you are using CMake then it should take care of everything provided that you instructed it to do so. phb provided a link to even better instructions.
First step is to instruct the CMake that we need Qt for our project. This is done with (you can specify individual parts that are needed as well):
find_package(Qt4 REQUIRED)
If Qt is not found in the typical locations (e.g. QTDIR is not set) - cmake will fail.
You also have to instruct CMake to use Qt include paths and set certain compiler definitions:
include(${QT_USE_FILE})
add_definitions(${QT_DEFINITIONS})
Finally, for each target you need to tell that you'd like to link with Qt libraries:
target_link_libraries(foo ${QT_LIBRARIES})
You might also want to process your headers and will have to process the user interface files with moc. For the details please refer to the provided links.
In addition to provided links you can have a look at the comments at the top of FindQt4.cmake file.