I'm using ccache with git-worktree. So many of the same files are shared across multiple directories. Problem is that ccache doesn't check if the file is the same, and is compiled again. Is there a ccache option that would allow it to check the cache across multiple source directories?
ccache (by default since version 3.3) adds the current working directory to the hash if -g is used, which only makes it possible to get cache hits within the same source directory. Another similar issue is if you use absolute paths in compiler arguments, then you need to use the base_dir configuration setting.
More details from the "Compiling in different directories" section in the ccache manual:
If you build with -g (or similar) to add debug information to the object file, you must either:
use the -fdebug-prefix-map=old=new option for relocating debug info to a common prefix (e.g. -fdebug-prefix-map=$PWD=.); or
set hash_dir = false.
If you use absolute paths anywhere on the command line (e.g. the source code file path or an argument to compiler options like -I and -MF), you must to set base_dir to an absolute path to a “base directory”. ccache will then rewrite absolute paths under that directory to relative before computing the hash.
Related
I'm trying to make ccache work with the same source code built from different sibling directories. I've successfully set CCACHE_BASEDIR to the parent dir of these two siblings. If I do a build in bld1 and then switch to bld2 and build that copy (again, these are the same sources), I get no cache hits.
I'm now looking at the log output from setting CCACHE_LOGFILE. Unfortunately the log doesn't tell me what factors/data went into computing the hashes it looks up, I just see lots of "No such manifest file" message (for direct lookup, it seems).
Are there any other options I can use to debug the issue with ccache to figure out why it doesn't recognize these two source trees as identical?
Just to be clear, if I repeat the build in a given directory, I do indeed get lots of hits in the cache - so clearly ccache is working with an unchanging build path, it just doesn't seem to be working properly across directories.
The solution is most likely to set hash_dir = false (CCACHE_NOHASHDIR=1 if using environment variables) or setting -fdebug-prefix-map=old=new for relocating debug info to a common prefix (e.g. -fdebug-prefix-map=$PWD=.). More details can be found in the "Compiling in different directories" section in the ccache manual.
I'm trying to figure out how to convince Yocto to build gcc using my local GIT source rather than standard location it uses.
By default the recipe to build GCC located in meta/recipes-devtools/gcc/gcc_5.2.bb. It includes gcc-5.2.inc, which points to
BASEURI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
as the location of the code.
Based on BitBake's documentation, I've created my own layer and gcc_5.2.bbappend append file. bitbake-layers show-appends shows that the system properly recognized the append file.
However, what this gcc_5.2.bbappend append file need to do to replace the source path? I've tried changing SRC_URI directly, prepending it with my own path. But it always stays the same and attempts to access the specified above path.
My original assumption that the /gcc/gcc_5.2.bb have to appended was incorrect. I've corrupted the specified above BASEURI to consistently cause an error. Running bitbake with -D option showed that there is a different recipe called gcc-source_5.2.bb that actually controls the source file acquisition and it had to be appended.
I have a matlab guide program I want to compile (package).
This program is not using the curve fitting toolbox.
Nevertheless the compiler complains about a missing licence.
mcc -C -o ...
Compiler version: 5.0 (R2013b)
Dependency analysis by DEPFUN.
Processing C:\Program Files\MATLAB\R2013b\toolbox\matlab\win64\mcc.enc
Processing C:\Program Files\MATLAB\R2013b\toolbox\curvefit\win64\mcc.enc
Depfun error: 'License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
How can I remove this dependancy for compilation?
According to the mcc document,
-N Clear Path
Passing -N effectively clears the path of all folders except the following core folders
(this list is subject to change over time):
matlabroot\toolbox\matlab
matlabroot\toolbox\local
matlabroot\toolbox\compiler\deploy
It also retains all subfolders of the above list that appear on the MATLAB path at compile time.
Including -N on the command line lets you replace folders from the original path,
while retaining the relative ordering of the included folders.
All subfolders of the included folders that appear on the original path are also included.
In addition, the -N option retains all folders that you included on the path that are not under matlabroot\toolbox.
In other words, you can clear all folders from the path and only keep the core MATLAB ones.
If you want to include some toolbox folders, you can use the -a option:
mcc ... -a C:\Program Files\MATLAB\R2013b\toolbox\...\...
Personally, I simply temporarily rename toolbox folders I don't need.
Just manually navigate to "matlabroot()\toolbox\" and rename, say, "signal" -> "signal_".
Surprisingly, the same could be done from the script, calling mcc() - almost no files in those folders are locked by matlab.exe.
This method doesn't sound like a "solution", of course it's just a "quick-and-dirty workaround". But, for me, it seem to work (R2015a).
Note, that you can easily check, what's actually included in your "deployed" dll (or exe), with 7z. Including files, added from toolboxes - see "my.dll.text\toolbox\"
PS1:
From my experience ,"-N" removes some unrelated stuff. Not all.
Moreover, when using "-N", you should carefully add stuff you need with "-I".
PS2:
In ".prj" file, created by deploytool(), there's something, that sounds related:
<matlab>
<root>D:\Program Files\MATLAB\MATLAB Production Server\R2015a</root>
<toolboxes>
<toolbox name="matlabcoder" />
...
</toolboxes>
...
</matlab>
but I've not checked, whether this actually controls witch toolboxes are used by mcc.
I am using Doxygen 1.7.4 for Windows.
In the File List page of generated documentation I'd like to see relative paths.
I have set FULL_PATH_NAMES = YES, to have something more, than just filename without path, but this gives full, absolute paths.
I want only paths relative to project directory. I know, that I can use STRIP_FROM_PATH but I have problem with wildcards. I need that kind of path-stripping, because this project is made on multiple PCs (as git repo), so paths can be different.
Is it possible to use wildcards for this setting, or do I have to set doxyfile for each workstation with part of absolute path to strip?
Edit:
I've found something like what I need on the doxygen website: STRIP_FROM_PATH = $(QTDIR)/
Maybe it is possible to use one of doxyfile's variables?
I'm not sure about Windows, but on Linux and OS X I can produce outputs in the file list like
src/Utils.cpp [code]
src/Utils.h [code]
src/VectorMath.h [code]
test/src/test.cpp [code]
By setting FULL_PATH_NAMES to YES and STRIP_FROM_PATH to ../.. (i.e. the directory path of project's root which is two directories up from where I'm building the docs). You may need to swap the directory separator to the windows one.
You'll also need to watch out that you update the Doxyfile if you move the docs around.
I'm trying to compile C shared library from Matlab. My Matlab code uses a lot of the image processing functionality. So, compiling goes fine, but when I call the dll from my application, I get messages like:
"Undefined function or method 'XYZ' for input arguments of type double".
I have verified my arguments are ok -- it's not a type problem. So, I tried adding %#function XYZ to my .m file, but that didn't help anything. Then, I tried using the -a flag in my compile command:
eval(['mcc -v -N -W lib:cshared -d ' clibdir ' -T link:lib -a edge' allFiles]);
but it fails to compile with:
Depfun error: 'Unable to locate edge as a function on the MATLAB path'
I have verified the image processing files are on my computer (I can run everything from matlab with no problem) and my path points to the directory that contains them.
I've also tried copying the toolbox .m files into my working directory, but that quickly balloons into a lot of files. And, for some functions, there is no .m - just a .mex - and i haven't found a way to include a mex file into my .dll.
What am I missing?
Have you tried including the Image Processing Toolbox folder using the -a option? For example:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images
According to the mcc documentation, all files in this folder, as well as all files in any subfolders, are added to the CTF archive, and the folder subtree is preserved in the CTF archive.
If you don't want to include every subfolder, you can load only the files in a folder using a wildcard pattern:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images\*
This may be necessary if there is a subfolder that may have functions or scripts that could shadow ones in the parent folder. For example, there is an edge.m function in the parent folder C:\Program Files\MATLAB\R2009a\toolbox\images\images\, and there is a ja subfolder that contains Japanese language help files (on Windows), one of which is also called edge.m. You wouldn't want this subfolder to be added when compiling, so you could either:
Remove that subfolder temporarily, add the parent folder without the wildcard option (to add the other subfolders you do want), then put that folder back.
Add the parent folder with the wildcard option (to add just the files), then separately add only the subfolders you want (such as #strel and private) with an additional -a command. NOTE: I'm uncertain if adding subfolders separately will maintain the folder subtree of the parent directory in the CTF archive in the same way as option #1 would!
If you don't want to include a large list of files that may not end up being used, you could instead try using the function DEPFUN to first get a list of dependencies for your MATLAB code. Then from this list you can find the specific Image Processing Toolbox functions your code uses and include only those when compiling. Since you specifically asked, this newsgroup thread mentions how to include a .mex file:
mcc ... -a imreconstructmex.mexw32 %# For a 32-bit Windows mex file
NOTE: There is also a MathWorks bug report I came across (which you need a login to see) that mentions a problem compiling applications using some Image Processing Toolbox functions on Windows in R2009b. There is a workaround given at the above link. This bug is fixed as of R2010a.