I have a project with the following dir tree structure:
CMakeLists.txt
\src
test.cpp
\include
test.h
\resources
various resource files
test.cpp contains the correct path (relative to the root) in order to point to the resources in the resources dir.
When running CMake with an out-of-source building in the build directory, the \build directory is created as subdir of the root, but now the resources pointed by previously correct paths hard-coded in test.cpp cannot be accessed anymore, because the working dir is not the root.
How can I manage resources with CMake and out-of-source building??
It's up to you as program author to make sense of relative paths. With a relative path, you must always be clear about what it's relative to. "Source file directory" is a terrible reference point, since it doesn't exist at runtime.
Is a path relative to the current (= working) directory? Then that's beyond CMake's control and you must launch your program correctly. For tests purposes, you can set test property WORKING_DIRECTORY.
Is a path relative to the executable location? If so, you can either position the executable through its RNTIME_OUTPUT_DIRECTORY property, and/or copy the resources to the proper place using file(COPY) or configure_file(COPYONLY).
Related
How do you specify a directory - the following only work if I put my helloworld.proto in a folder named protos
protoc --dart_out=. -Iprotos helloworld.proto
protos: warning: directory does not exist.
helloworld.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).
You should not need to include -I in this case because helloworld.proto is in the current working directory.
-I (proto path) is used by protoc to reference directories that aren't in the current working directory. If you were to use ${PWD}/helloworld.proto for example, I think you'd need need to -I=${PWD}. Even though ${PWD} is equivalent to the current working directory, protoc sees a proto with a directory prefix and expects it to be added to the proto path.
Customarily, you'd need to add a proto path when you have protobuf imports that aren't local. Then, you add -I= and list the directories where these imports may be found.
I've been trying to add additional functionality to the electron installer, where I copy some files that are packaged inside the installer, but I receive a non-descriptive error when I try to compile my electron project to create the installer i.e. I get:
* writing effective config
* packaging
* building
x [object Object]
Here is what my script looks like:
!macro customInstall
Rename "$APPDATA\myfolder\img" "$APPDATA\myfolder\img-old"
SetOutPath "$APPDATA\myfolder"
File /nonfatal /a /r "additional_files\*"
CreateShortcut "$SMSTARTUP\mylink.lnk" "$INSTDIR\mylink.exe"
!macroend
Basically everything works except the file copy part. When I remove that part the project builds and compiles into an installer with no problems.
I've also tried to use CopyFiles instead of SetOutPath and File and it works as expected when I place the additional_files folder into the same folder as the installation (dist folder), but I want the folder to be packaged inside the installer. However, I cannot get the additional_files to be packaged with the installation.
I believe it's a location issue, that is, that the NSIS script cannot locate the additional_files/ folder. I've tried modifying the package.json file by adding to the files section the additional_files/ folder and placing it in the root of the project.
I've even tried placing it in the build folder where my installer.nsh script resides, but with no luck.
File looks for files relative to the directory where the .nsi is by default. /NOCD can be used to prevent that but I'm not sure if electron uses that switch.
!cd can be used inside a script to change the directory but I'm not sure if that is going to help you much in this case unless you are willing to use a absolute path and in that case you could just use the absolute path with the File instruction instead.
If you only know where your .nsh file is I suppose you could try File /r "${__FILEDIR__}\additional_files\*"
if you are using electron-builder you have two options inside the settings
extraResources this will copy files into the $INST_DIR/resources folder in your app (this is where the app.asar file is too), and you can access via process.resourcesPath, ex:
extraResources: [
{ from: './dist/ThirdPartyNotices.txt', to: 'ThirdPartyNotices.txt' },
]
extraFiles this would do the same but place the files into the $INST_DIR root folder of your installation ex:
extraFiles: [
{ from: './distrib/mytool.exe', to: 'mytool.exe' },
],
to get the root folder you can use something like remote.app.getAppPath().replace('resources\\app.asar', '').replace('resources/app.asar', '');
all info on: https://www.electron.build/configuration/configuration#overridable-per-platform-options
I am trying to figure out how to use relative paths for Powershell scripts. I have dot sourced with absolute paths, but the scripts that I am writing may end up in a different base directory so I need to make sure the path is relative so it can be picked up. How can I do that?
So far I have tried:
. .\scripts\variables.ps1
That always throws this exception:
The term '.\scripts\variables.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program...
That lets me know it can't find my script? So, what am I doing wrong?
You can use : . $PSScriptRoot\scripts\variables.ps1
Here $PSScriptRoot is the path of directory of the running script.
This is not what the OP asked for but may be useful for others who are searching:
If you need to traverse up, you can use . $PSScriptRoot\..\scripts\variables.ps1
This works for structures such as:
root
scripts/shared directory
directory your script is executing in
If you know that your script directory structure is going to remain the same, you could use $PWD; eg:
. "$PWD\scripts\variables.ps1"
The above assumes that your script (the calling script) is in the same directory that contains the scripts directory.
Also, the assumption made here is that you're checking out/downloading all your scripts in the same structure, but as you put it, they may end up being in a different base directory.
Hi I have the following directory structure...
I enter this at terminal:
javac -d bin src/com/elharo/math/Fraction.java
and the Fraction.class file gets placed in bin/com/elharo/math instead of bin/
I just wondered why the compiler placed the file there. Is it that the point of having source and bin, so that when you compile a source file it goes in the parallel/mirror bin directory?
The output path will be computed from package and class name of the public class that must be defined in the java source file (which must, incidentally, match the file name minus ".java"). And it will be relative to the directory in the -d option, or relative to the current directory.
This is as expected. /com/elharo/math is the package the class exists in. If you took the class out of this directory an just put it in bin you would like get a noclassdeferror.
I have a project in directory A and files that I use in all my projects are in directory B.
When I moved a .sty file from A to B, the main .tex file does not compile anymore.
The error is that the .sty file was not found. I am puzzled because:
Directory B is included in the path of the project.
I cleaned (deleted manually) all the auxiliary files used in the previous compilations.
I refreshed the project folders .
Did anyone had similar problems? Suggestions?
The file LaTeX.sublime-build, within the Sublime Text folder . . . /Packages/LaTeXTools, contains a $PATH for different operating systems.
For example, Sublime Text 2 on an OSX operating system, has a file located at ~/Library/Application Support/Sublime Text 2/Packages/LaTeXTools/LaTeX.sublime-build. The relevant line of code for a MacTeX TexLive 2012 installation is "path": "$PATH:/usr/texbin:/usr/local/bin",. The plugin LaTeXTools looks in that path for *.sty files that are a part of the TexLive installation. While it may be possible (under some circumstances) to place the *.sty files within the working directory of the *.tex file, this particular plugin looks to the path mentioned hereinabove. So one option would be to add additional locations to the $PATH to suit the needs of the user, or simply place the *.sty files within the path that is pre-defined by the plugin developer.