I am using WiX 3.5 and making an installer. I have used heat.exe to bundle all the files.
It produced a WiX file. I referred in main wxs files as componentgroup ref. When I build my installer, it throws the following exception.
light.exe : error LGHT0103 : The system cannot find the file
'..........\target\tmp-release\jboss-eap-5.0\jboss-as\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet\ReadOnlyAccessFilter.class'
with type ''.
It is able load many files from this location, except the above file, even though the file is present.
Looks like you've hit the linker bug. As far as I can see, it was already reported to the WiX team, and was scheduled for v4.0. The comment to the issue states the path is more than 255 characters, so a possible workaround for you is to re-work the files/folders layout to avoid the paths of that length.
Hope this helps.
The answer of Ravz1234 works ! I used it with a environment variable e.g. env.SourcePath.
1) Set an environment variable to show on your Source Dir e.g. C:\SourceDir
2) On heat.exe add the argument -var env.SourcePath along with the other arguments
I used the variable for the directory, sys.SOURCEFILEDIR, and it worked well.
Related
while building a project in VisualStudio 2012 I get the error message
LINK : fatal error C1905: Front end and back end not compatible (must target same processor).
Checking the project manually does not help, all involved (static) libraries have been built for the same processor. I also added
/VERBOSE:lib and /VERBOSE
to command line to get some more information but this does not help, only additional output line I got by this was a stupid
Starting pass 1
So: any ideas how I can find out what causes this strange error message? How can I get more output from the linker?
Thanks!
Old question and I'm not sure whether anyone still need an answer. I had this problem with Visual Studio 2017.
Check paths for generated .obj files, especially when you use some .cpp files in more than one project (within solution) and/or use %(RelativeDir) variable in Properties -> C/C++ -> Output Files -> Object File Name. It happened to me with this path in Object File Name '$(IntDir)\%(RelativeDir)' and this $(ProjectDir)Junk\$(Platform)\ in Intermediate Directory. Error gone when I moved $(Platform) part to Object File Name.
Old paths:
Intermediate Directory: $(ProjectDir)Junk\$(Platform)\.
Object File Name: $(IntDir)\%(RelativeDir).
New paths:
Intermediate Directory: $(ProjectDir)Junk\.
Object File Name: $(IntDir)$(Platform)\%(RelativeDir).
You can also specify Object File Name option for each file, shared between multiple projects to keep using old path (or if new paths configuration isn't working for you) and get rid of that error.
I am trying to port a new module into my project. The module has its own make file. I have no background or experience with the make build system, so I decided to use the following command:
make -f Makefile -f ../newmodule/tbt/makefile
But I get the following errors:
../newmodule/tbt/makefile:14: make/macros.mk: No such file or
directory
../newmodule/tbt/makefile:66: *** target file `all' has both : and :: entries. Stop.
Please correct me if I am wrong; it is my understanding that my first error is because I issued make from my main project, and I need to somehow configure it to look into the directory of ../newmodule/tbt/make to find macros.mk. Would anyone be able to suggest an effective way of addressing this issue? What is the best way to include the contents of ../newmodule/tbt/make folder?
My 2nd error seems to be exactly what make complains about, which is having : and :: in the two make files for the target "all". I can not follow the 2nd make file very closely, but there is not much to the lines that have this target. I am thinking of changing it to My_all, and configure this new variable as the default target of the new module. I am not even sure if my terminology is correct. "all" is called the default target for make right? I have reviewed most of the make file document, but it is 5 am, and I do not recall some things.
I came across this error during compilation of some package under OpenWrt. The problem was in the VERSION declaration in the Makefile.
So, check if you have declared anything with unnecessary spaces or comments after some variable.
Removing the comment or space after variables should work.
Try running two separate make -f myMakefile commands, one from each module directory so that the relative paths work out properly as you have already observed that you current directory when executing make may be part of the problem.
I am trying to include a file in my resource bundle the files contains the following:
LeadPunc="({[`'
TrailPunc=}:;-]!?`,.)"'
NumLeadPunc=#({[#$
NumTrailPunc=}):;].,%
Operators=*+-/.:,()[]
Digits=0123456789
Alphas=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
*extra line*
The files is called:
eng.cube.lm
The error I get is:
IExpenseReporter/tessdata/eng.cube.lm:6: premature EOF
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lex failed with exit code 1
This file goes along with the newest version of tesseract (OCR). Does anyone have an idea what is causing this error and how to fix it?
Make sure you select the "Create folder references" option when adding the tessdata folder to your project.
From the documentation:
NOTE: This library currently requires the tessdata folder to be linked
as a referenced folder instead of a symbolic group. If Tesseract can't
find a language file in your own project, it's probably because you
created the tessdata folder as a symbolic group instead of a
referenced folder. It should look like this if you did it correctly:
Note how the tessdata folder has a blue icon, indicating it was
imported as a referenced folder instead of a symbolic group.
Trashing the current folder and adding it again as a folder reference should solve the problem.
XCode "thinks" this is a lex file and try to process it by calling lex. However, lex finds and unbalanced quote and thus a premature end of file.
You should try to call the designated tool explicitly.
I had this issue and I found that copying the folder "tessdata" from the language zip into the project directory rather then into Xcode fixed the issue.
After wasting some time to figure out what goes wrong, I finally have to ask for help. I want to use appledocs from Gentle Bytes. I followed every step of the quick install guide, but I´m not able to compile the project.
Here is what I´ve done:
1. cloned it from git://github.com/tomaz/appledoc.git
2. installed the templates to ~/Library/Application Support/appledoc
3. tried to compile the project
Everytime I try to compile, I get following error:
ERROR: AppledocException: At least one directory or file name path is required, use 'appledoc --help'
What do I have to do now?
Sounds like you've compiled it just fine and are now running the program. If it's a command-line program try command-option-R in Xcode to provide some arguments (i.e. names of files that you want to process).
The error means you didn't give it source paths: after all switches, you must give it at least one path to your source files. Can be either file or directory. In later case it will recursively scan the dir. Here's example
appledoc <options> ~/MyProject
Above example will use ~/MyProject directory as a source. You can also add multiple source paths. Note that you need to give the tool few options, see this page for minimum command line and other usage examples.
You either have to copy appledoc executable to one of directories in your path, as suggested by Caleb, or use full path to it when invoking (for example: /path/to/appledoc)
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.