I am trying to load my project using a self-made .asd file, but somehow asdf does not recognize that the .asd file should also be the root-directory of the project and therefore resuling in an error like failed to find the TRUENAME of /home/$USER/rel-path-to-file where rel-path-to-file is the path to the corresponding file, relative to the loaded .asd file.
This is what I did:
(push "path-to-project-directory-of-asd-file" asdf:*central-registry*)
then
(asdf:load-system 'project-name)
It DOES find my .asd file but somehow not the .lisp files it shall load.
The asdf has been configured and installed by quicklisp. Therefore I also "installed" the project into quicklisp using a symlink, this worked as well. It DOES find the .asd file using ql:quickload :name but still doesn't use the directory containing the .asd file as the project-root.
How can I fix this?
Lisp pathnames are historically such that they require you to add a slash after directory name (I was told this is so due to the operating systems which were created before I was even born), so in order to tell Lisp that you target a directory you must end the name with the slash.
See asdf:system-relative-pathname.
Related
From How to specify additional files as prerequisites that would cause ASDF to recompile the program, I learned that the ASDF static-file directive can be used to list non-Lisp files that a Common Lisp program depends on. For example:
(defsystem "myprog"
:components ((:static-file "1.txt")
(:static-file "2.txt")
(:file "myprog" :depends-on ("1.txt" "2.txt"))))
This requires the programmer to explicitly list out the static files. If there are many static files, and all of them reside in a directory and its sub-directories, it may become impractical to list out all the static files by hand. Is there a way for ASDF to consider all the files in a directory and its sub-directories as static files?
In fact, you can just use the same :static-file "directive" to indicate a dependency on the files in some directory. Or rather the presence of the directory itself (possibly, with some files in it). Theoretically, you could add a separate :static-dir dependency class with some special processing. But the question is what will this special processing constitute? If you don't want to manually specify an exact list of files (which can already be done with (:module "dir" :components ((:static-file "file1") ...))) what other additional processing do you want for this dependency class?
If I have multiple binaries whose sources are scattered in various subfolders of an overlaying folder, would windbg have access to them if only the topmost folder was included in Source Path? As opposed to having to reference each project folder of each relevant binary separately.
Assuming, of course, that the sources are unique in the mentioned folder structure, i.e. there are no multiple versions of one and the same project, source, etc.
If you specify the parent folder for the source files in source path then it should traverse through the subdirectories to find the source files.
Note that it will perform a signature match against your source files, in the same way that Visual studio will complain that the source files are different to the loaded dlls.
The relative locations of the source files must match the original locations so if your source files are located in a different structure then you will need to do a manual load/browse to specify the location of the source files.
Can’t answer exactly, but I often have 3 top (parent) directories, and each have approximately 4-5 levels of sub directories. No problems. However nothing beats using a source server
Short answer: NO.
From windbg's help:
For each directory in the symbol path, the debugger looks in three
directories. For example, if the symbol path includes the c:\MyDir
directory, and the debugger is looking for symbol information for a
DLL, the debugger first looks in c:\MyDir\symbols\dll, then in
c:\MyDir\dll, and finally in c:\MyDir. The debugger then repeats this
process for each directory in the symbol path. Finally, the debugger
looks in the current directory and then in the current directory with
\dll appended to it. (The debugger appends dll, exe, or sys, depending
on which binaries it is debugging.)
You can move all projects' .pdb files to one folder or change projects properties and setup the linker to create the .pdb file in a specific folder so you have to reference only one.
I've been doing a bit of debugging on this myself. From what I can tell, the relative path of the file found from the SourcePath needs to match part of the end path of the path embedded in the PDB. For example:
I have a file on disk at:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\thread_local_key.rs
The path of the file embedded in the PDB is:
/rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs
✔ This SourcePath, and any below it, correctly finds the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust
❌ This SourcePath, and any above it, does not find the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src
Notice how with the failure case, the relative path to the file would begin with library\. The library path component is the first part of the path that is not found in the embedded path. I assume it does a path check for every relative address, recursively:
thread_local_key.rs
windows\thread_local_key.rs
sys\windows\thread_local_key.rs
src\sys\windows\thread_local_key.rs
std\src\sys\windows\thread_local_key.rs
library\std\src\sys\windows\thread_local_key.rs
etc.
I want to copy a data file from a directory in my source tree to the directory of the linked app so it's available at runtime, on Windows only. There appear to be two suggested techniques: use a post target dependency to issue a DOS copy command (Including resource files in Qt Creator build directory) or use an install step (Copy a file to the build directory after compiling project with Qt), but I cannot make either work in the way I would like.
The former requires me to use qmake path variables to generate my source and destination paths, but they contain backslash path separators, which the DOS copy command cannot handle.
The install solution forces other users of my project to set up a post build step in Qt Creator before it will work (one per configuration, in fact) and I would like to avoid this, as I want to make my project work with a default Qt Creator installation.
Is there any way to do this apparently simple task that can be wholly defined in the .pro file for the project? For example, is there a way to expand qmake path variables in a platform specific way?
Though these commands run ONLY after the executable is ACTUALLY linked, this solution doesn't require an external batch file. Note: this a Windows-only solution:
From our .pri file:
win32 {
...
# Copy the appropriate dll files into the target destination directory.
QMAKE_TBB_LIBDIR = $$quote($$PWD/MySource/MyLibs/$${PLATFORM_NAME}/vc9)
QMAKE_POST_LINK = copy /y $${replace(QMAKE_TBB_LIBDIR, /, \\)}\\*.dll > $${replace($$quote(DESTDIR), /, \\)}
...
}
This places a command in the Makefile that copies all the .dll files in MyLibs/x64 or MyLibs/Win32 into the destination directory.
However, if the executable did not need to be linked, then the .dlls are NOT copied.
The post build batch file would not have this limitation.
I am new to cl, and I just learned to install packages using asdf-install, but I don't know how it works, I wonder how the package can be installed manully, then I could understand the use of the files in the root directory of the source code, thanks.
Short answer: Just use quicklisp.
Long answer: if you want to understand, how the package, or - more precisely - ASDF system, is laid out, that's a good idea. Actually, there's nothing hard about that.
Every ASDF system should have a system definition file with .asd extension. This file names other file of the system with their paths relative to the .asd file, their types (by default: lisp source code) and dependencies. Your Lisp should know where to find the system definition file. In ASDF there are 2 ways to inform Lisp about it: adding the directory, in which you store the file or symlink to it, to asdf:*central-registry* list or setting up special configuration files (called source-registry - more on that in ASDF manual).
Now if you want to install the system by hand, just download its sources, extract them into some directory (like in /home/user/lib/lisp/ - you may get /home/user/lib/lisp/cl-ppcre-2.3.1/, inside which there's cl-ppcre.asd). To let your Lisp find out about it just (push "/home/user/lib/lisp/cl-ppcre-2.3.1/" asdf:*central-registry*) (and don't forget the trailing slash - it's required), and then you can load the system with (asdf:oos 'asdf:load-op :cl-ppcre).
You might also setup a special dir, where you'll symlink your existing systems, like /home/user/.lisp/ and add it to *central-registry* at Lisp startup type (e.g. in .sbclrc). Now if you want to temporarily override some of the system linked in this dir, say, with a newer version, you don't need to unlink anything - just push the path to alternative system to *central-registry*.
Quicklisp does all that for you and more...
I have a bunch of JAR files (from a maven2 project) and maven reports some package could not be found (org.openanzo.client.jena to be exact). I want to dig into the JAR files downloaded as the result of maven dependency resolution and find what packages are thus available from these JAR files. Insights?
UPDATE: Apparently, the only good solution to inspect insides of a jar file is the "jar" utility or one can use the facilities of their IDE to do so.
jar tvf filename.jar will show you the contents of a jar file without requiring you to extract it.
But I think that maybe what you are really trying to do is find the right coordinates for the dependency that you are missing, since obviously none of the ones you have right now are supplying the package you are looking for (in other words, checking their contents is not likely to help you).
I confess that the first place I would suggest to check is Sonatype's public Nexus instance. A search for your example turns up nothing, though. Usually that means the project is not trying to get their stuff into Maven Central or other major repositories (which is okay), so you have to resort to a web search. Usually the first two sections of the package tell you where to look (openanzo.org in your case).
If you are on Linux or a Mac, you could go to the terminal at the root of the folder containing your JARs and type:
# grep -ri "org.openanzo.client.jena" *
It will return a recursive list of all JAR files that contain that package name. If it returns 0 results, then none of those JARS contain that package.
If you wanted to do a more exhaustive search, you could unJAR the JAR files. The directory structure and .class files will be organized by packages in folders.
# jar xvf filename.jar
If you are on Windows, you can unJAR a JAR file using a tool such as 7Zip.
#Carsten
you do not have to rename a .jar file to .zip. You can directly open the jar file in winzip/or other zip utility (assuming windows OS)
#ashy_32bit
try using "jar class finder" eclipse plugin from IBM. Simple plugin for finding classes (if you know the class name)
OR
as carsten suggested... set the jar files as lib files and manually look it up
OR
create a batch file called a.bat (where you have all your jar files directly under a single folder) and paste the following 4 lines
#ECHO OFF
dir /b *.jar > allJarFilesList.txt
FOR /F %%A IN (allJarFilesList.txt) DO jar -tf %%A > list_of_packages.txt
FOR %%B IN (list_of_packages.txt) DO FIND /I "com/sun" %%B
NOTE the "com/sun" in the last line.. it is hard coded, you can pass as argument as well...
I know this is very basic form and can be improved "a lot" like looking up in various sub directories.
hope this helps :-)
.jar files are just ZIP compressed archives, rename it to zip, open it with your favourite unzip programm, and traverse through the directory.
If you add the jar file to a eclipse project, you can traverse through the lib in th project explorer.
HTH
Assuming maven downloaded the jar files,the files will be loaded in to a local repository.
You could use maven browser that comes packaged with Eclipse to browse and search for artifacts in your repository.(usually in userdir/.m2/repository)
Note:You can explore your repository directly if you want. You will understand the packages that were downloaded. But I suggest using the plugin.
If you are using Intellij IDEA, each project contains a tree called External Library that allows you to search and explore your libraries.