I built air app with icon in the past with flash builder, and everything was fine.
Now I have to build another app with adt(air developer tool), but I experience weird problems.
If I just place icon path relative to 'src' folder to app descriptor (as usual), it says:
error 303: Icon icon.png is missing from package.
If I use icon.png without path in app descriptor and then put this file everywhere(to root dir, to assets, to src, to build destination and so on), it again says error 303: Icon icon.png is missing from package.
If I try to add icon path to adt args like <arg value="icon.png"/> ( and put it to output folder as it seems that all path are relative to it in my case), it says The path icon.png is restricted. If you were trying to package Icon.png you should correct the case.
When I point to original file location ( <arg value="../src/assets/icon.png"/>), it outputs File ..\src\assets\icon.png is not relative to directory E:\projQ\flex\MyProject\bin (this bin directory is actually output directory). I've read unapproved comment on adobe forum that this is due to some sandbox limitations, but I'm not even sure that sandbox exists for adt( if it exists, then why? )
So, what shall I do to successfully add icon to that app?
I guess that using tools like resHacker to project's .exe will not help as .exe is just a launcher for .swf file, and anyway I consider that this awful way leads to the dark side of programming.
(P.S. can't add 'adt' tag that relates to adobe, not android.)
Nice. At last I've found the solution. So, the requirements for including icon while packaging manually with adt are:
Add file name to application descriptor without using any .. .
I beg you, don't even try to name your icon file icon.png. It is obvious name, and it was obvious for creators of adt. So it seems that they are renaming some files to icon.png or generating output to such file. Or put this file into some subdirectory of directory that is used as root by adt. Actually, error output exactly tells you to avoid using path icon.png. Correct the case phrase (which confused me) means rename your icon or move it deeper in directory hierarchy
Add path to your icon as command line argument to adt.
After generation you will see your icon inside generated output folder. You can remove it and application will still appear with your icon as expected.
This is more of an elaboration on the first point in the answer above to clarify for people like me who have been struggling with this issue.
The error reads "is not relative to directory", but what it means is "is not a child of directory". Basically even if you're trying to use a valid relative path, it expects it to point to something under your working directory. In my case the following trick worked:
./../..build/executable.swf
Replaced with
-C ./../.. build/executable.swf
-C makes ADT change directory to the one two levels above, and then you can specify the necessary file.
After playing with ADT a bit more, I now realise why it does that - the path you give to it will become the path within the package. So in the example above the file will be available inside the package at build/executable.swf. If you wish to make it available at package's root level, change the -C directive to the following:
-C ./../../build executable.swf
Related
I installed SASS on my machine via path ( environment variables ).
I can access help and other options(version etc.) but whenever I initiate
`--watch styles.scss:styles.css`
I get the following error :
`Error reading styles.scss: Cannot open file.`
I checked the documentation but to no avail. I get the same error when trying to get more information via
--trace styles.scss:styles.css
I found the reason of my self-inflicted error.
When you initiate
--watch styles.scss styles.css
make sure you add the directory in case you placed your css styles in an external folder
--watch css/styles.scss css/styles.css
Wow, thanks for your description of your self-inflicted error. It solved my problem of not seeing any output for half an hour. I had given the full path for the input file (path from the folder where the command runs to the input file), but had taken that the path of the output file would be relative to the input file (ie: the path from the input file to the output file), but it should also be the full path to the output file (path from the folder where the command runs to the output file). In fact easier, but if one has a wrong expectation in one's head it can take a long time to realize. Your description put me on the right track!
I have a solution with various projects, one of which is the main executable, and the rest are libraries the executable depends on. Each one compiles and links fine. However, trying to start the executable gives weird results. Using ldd, I see that the executable is trying to find libraries like so:
../bin/debug/libBlahBlah.so => not found
However, for each project, I'm declaring "bin/debug" (which is the output directory for these libraries) as a libdirs entry, and linking against the library by adding "BlahBlah" as a link, where "BlahBlah" is the name of the project.
I'm not even sure how to accomplish this without premake. Any help is appreciated.
The original intention was to have the library sit next to the executable then set an RPATH that searched for the library next to executable. With the way it is now, it searches for that absolute path relative to the executable... I cannot figure out how to get it off.
I'm using premake5. I've tried to use the nightly and compiling myself. Upstream is currently not compiling however.
If you are using the latest alpha or source of Premake5, you can use the "RelativeLinks" flag to use -L/-l instead of relative paths to libraries:
project "MyProject"
flags "RelativeLinks"
You will still need to set up the rpath properly though; you can do that with buildoptions() and the appropriate command line flags for your compiler. Maybe (untested):
buildoptions "-Wl,-rpath=."
That should work in Premake 4 as well.
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 am trying to link my AVR cross target application to my AVR cross target library.
The library is named Lib328P and the application is named LibTest. I have built the library and verified that the .a exists in the filesystem.
I am trying to link the library by Right clicking on the project>Clicking on C/C++ Build> Settings > AVR C++ Linker> Libraries adding Lib328P to the -l category and "${workspace_loc:/Lib328P}"
to the -L category
Here is the output to the console.
**** Build of configuration Debug for project LibTest ****
make all
Building target: LibTest.elf
Invoking: AVR C++ Linker
avr-g++ -Wl,-Map,LibTest.map,--cref -L"C:\Users\kempsa\indigo_workspace\Lib328P" -mmcu=atmega328p -o "LibTest.elf" ./something.o -lLib328P
c:/arduino-0023/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: cannot find -lLib328P
make: *** [LibTest.elf] Error 1
**** Build Finished ****
I have looked at the other posts and they suggest removing the lib and .a suffix. I am already doing that. Any help would be appreciated.
Thank you!
Sam
In your case, the linker is expecting to find the file:
C:\Users\kempsa\indigo_workspace\Lib328P\libLib328P.a
Are you sure it is present at that location? Or is it in a subfolder, possibly Release or
Debug?
This is the process that works for me:
When adding a library to be linked with your program, you make two entries. The entries are found on the project properties page by navigating to:
C/C++ Build > Settings
On the right pane, be sure to select whatever Configuration you are building at the top drop down box. (Occasionaly I make changes to the wrong configuration and wonder why those changes do not seem to occur.)
On "Tool Settings" tab is a navigation tree. On that tree, select
AVR C++ Linker > Libraries
On the right pane are two list boxes: Libraries and Libraries Path. These are where you add the two entries.
1.. In the top box, click the plus or + icon. Here you enter just the library base name. This is the library name without the "lib" and without the ".a"
For example, I have one "LibCore328v101".
That will cause the linker to look for a file "libLibCore328v101.a"
2.. In the bottom box, click the plus or + icon. Here you add the path to find that library file.
2a. You can simply type the path to the folder that contains the .a file.
2b. You can click the Workspace... button and navigate to the folder that contains your library. If you keep your libraries and programs in the same workspace this is a better method to specify a path. I use this, in in my example this text is created
"${workspace_loc:/LibCore328v101/Release}"
This is essentially a relative path to the library. This means you can create an entire duplicate of your workspace and all the library includes will still be correct.
When you see the linker output in the console window, you should see both options. In my example these are:
-lLibCore328v101 (lower case ell)
-L"F:\arduino-src\tt-wb-trunk-hg\LibCore328\Release" (upper case ell)
You can see that the Eclipse plugin has converted the relative path to the current absolute path. The linker will internally add the "lib" and ".a" to the library name.
You can repeat this process adding as many libraries and paths as needed.
For your multi-target programs, you create a different configuration for every build target. So instead of Debug and Release, you have "DebugNano" "DebugTiny", etc. For each configuration, change the path to the library.
I have created an application that compiles and runs like a charm on OS-X. I would now like to start getting it to work on Windows. To start, I copied the project to a windows machine and just tried to compile, but got this error:
:: warning: Qmake does not support build directories below the source directory.
Any ideas?
Set the shadow build directory to some folder on the same level of your project directory:
folder/
project/
project-shadow-build-release/
project-shadow-build-debug/
You can do this in the "Projects" view, via the toolbar on the left. To me, this warning was just an annoyance, a project never failed to build because of it.
Don't copy your project.pro.user file when you are copying a project from one machine to another, or from one directory to another. When you open the project, Qt Creator will offer to create a new build directory in the proper place.
Andref gave the correct answer to resolve this warning, but you may want to understand why this requirement exists.
In fact, the build directory must be at the same folder level as the project (i.e. it can't be above or below). The reason why is that the linker is called from the build directory. Hence, any relative paths to library files will be different than what you entered in your project file.
It kinda sucks. I like to put all intermediate files in their own folder. But you simply can't with qmake.
.pro.user are generated files by Qt Creator. They are unrelated to qmake and should not be touched (and not put into a VCS for that matter)
Just remove the files with the pro.user extension , worked for me
I also got this, trying to compile a project created on linux.
Another way to solve it is to change the paths in the .pro.user file (in the directory of your project)
Right Click on a project: Set As Active Project
Click on the Projects button (The one with the spanner image)
Edit build configuration : Debug / Profile / Release / and change the default directories, OR just uncheck the Shadow build check box.
The Build directory path should now change to black, from red