I am working under linux/unix (ubuntu centos darwin)
I often build from source and install my biotools folders in a non-canonical place in order to have full write access to that place for all users and also to avoid overwriting/conflicting with important files placed by the OS in /usr/... and /usr/local/...
I put the tool build folders in /opt/biotools and alias all exe files in /opt/biotools/bin (which is in my PATH)
Now some apps need to access dependencies or libraries usually written in /usr/local/share or /usr/local/lib, ...
Is it possible to add such folders like /opt/biotools/share, /opt/biotools/lib, ... and have the system find them?
Should I add these folders to the PATH?
Thanks for your help
Related
the similar error occurs every time for packages like dplyr,data.table.
If you can't or don't want to make the default folder writeable (often we don't want that, depending on where it is), then choose a great spot on your computer where you want the libraries you install and then place this in your .Rprofile file (often in your My Documents folder
.libPaths("full path to your personal library folder")
This will not overwrite the default .libPaths; it will just append your personal folder to the folders that R knows about already (so it can still find the system installed libraries)
On GitHub I can view symlinks as text - they are just a path to the target.
However, if I edit a symlink in Atom it opens the file that the symlink points to. This is reasonable behaviour but not what I am trying to do.
Can I edit them in a similar way using Atom on my local machine?
If now, is there another text editor that can?
You can't change a symbolic link's target by editing the symlink file.
There are cases where the target of a symlink is stored in the symlink file, but that is not usually the case. For most target paths, the target is stored in the inode data directly.
Then there are symlink-like things various filesystems have implemented, such as macOS aliases, or Windows NTFS which has symlinks but they are not exactly the same as Unix/POSIX symlinks.
To manage symlinks you should be using the tools your OS provides, such as the ln command.
That said, I'm not aware of any packages for Atom which offer an in-editor method of managing symlinks. The tree-view package does not seem to offer it.
We want to upload files to a WebDAV-Folder and tried to use the "Windows Machine File Copy"-task for that (this uses ROBOCOPY inside). But we don´t see any possibility to enter the destination folder in the right form.
1. We tried
\\our.website.de#SSL\DavWWWRoot\remote.php\webdav\
and
2. we also mounted this location as a network drive first and tried to use the drive letter,
but none of these attempts succeeded.
Is "Windows Machine File Copy" the right type of task for that or is there any custom task out there that accomplishes what we need?
Thx...
You should separate specified Machines and the folder path. Do not use it together.
Machines:
Example: dbserver.fabrikam.com, dbserver_int.fabrikam.com:5986,192.168.34:5986
Folder Path:
The folder on the Windows machine(s) to which the files will be
copied.
Example: C:\FabrikamFibre\Web
More detail info please refer this link: Deploy: Windows Machine File Copy
When I release my Qt project, I want to redistribute the QtCore5.dll and Qtxxx.dll files.
How can I make myapp.exe to find them automatically?
The best way of doing this seems to be by editing a qt.conf file placed in the same folder as my executable.
myapp.exe is in c:\myapp\bin folder
The dlls are in c:myapp\common folder
"Better" way is to put your qt.conf into your resources :/qt/etc/qt.conf. This way has highest priority for resolving platform dependencies.
In our project we use cmake to generate necessary qt.conf file: in debug mode we put path to installed Qt binaries and in release - to local (deploy) folder.
Qt5xxx.dll files are linked, so you should place it in same folder, or make them available throught PATH environment variable. If you really want such exotic redistribution system (please, say real reason) - you may create your own platform-specific launcher, that will load necessary .dll's from any path.
Just put all required dll files into the same directory as your executable.
Note, that there are more files to distribute than just Qt*.dll - you will need proper plugin from platforms subdirectory and many more. Read Qt documentation on deploying application under Windows - it will teach you all required files.
Just assume we are installing some libraries from its source distributed by the way GNU promoted. When using "./configure --prefix" to specify where to install.
(1) does Make generate the binaries under the current directory? Does Make install then copies them from the current directory (which is from where Make is run) to $prefix? If the answers are yes, I have two questions, each for different cases.
(2) when the current directory and $prefix are not the same, can I remove all the files generated by Make under current directories to save some space?
(3) when the current directory and $prefix are the same, will make install do nothing or copy the files to themselves? Can I just skip the make install step?
The answer to your first question is probably yes.
As for the rest, you may find a make clean which will tidy up the files created by the initial make.
I think the makefile will be able to handle the situation where current directory and $prefix are not the same, and do the right thing.
The current directory would not usually be the destination of files created by makefiles.
(of course it depends on how the makefile is written, so I can't give definite answers, but I've generally been impressed with the makefiles I've used)
You are absolutely right: make just creates files in current directory and make install copies it to the destination directories, based on $prefix and other variables maintained by configure script.
You can wipe out the whole directory you've ran the build at. It will not be used, because, well, that's what "install" means: you build in one directory and the the files are placed in the proper places of your system.
Usually install destination and the directory you build in differ. The hierarchy of the files being installed usually do not relate to directory hierarchy of the build system. Just install to the other dir: it's cheap to create just yet another directory.