Just yesterday I started getting a message in terminal when I tried to compile a tweak. It said
make[3]: Nothing to be done for `internal-bundle-compile'.
The .deb is still built, but when I install it on my device, the preference bundle doesn't show up in settings.
make[3]: Nothing to be done for `internal-bundle-compile'.
Making stage for tweak test...
Making stage in prefs...
Making stage for bundle prefs...
dpkg-deb: building package `com.myname.test' in `./com.myname.test_0.0.1-14_iphoneos-arm.deb'.
I know there's no problem with my code, because I get these results on tweaks I've successfully built in the past, and have not modified since. Been trying to figure this out for several hours with no luck.
Related
I have been trying to use Systemc2.3.4 instead of 2.3.3. I have installed 2.3.4 and have run a small sample program which ran. I am currently testing out the example provided within "/systemc/examples/sysc/". Whenever I run make for any of these programs I am met with:
make: *** No rule to make target '/opt/systemc/lib/libsystemc.a',
needed by '-----.x'. Stop.
I have checked /opt/systemc/lib/ and there are only .so files present! Did I do something wrong in terms of the installation? or should I be doing some editing in the makefiles for these programs?
I should also point out that "make check" had 0 fails when I run it after make command. And that log showed the target for simple_fifo.x was built and successfully tested. What am I missing?
When i tried to build and run my project im getting this error.I tried may steps like clean and run, check with workspace.project but still im getting the error.No further details were in the error message. "Linker command failed with exit code 1(use -v to see invocation)
There can be many reasons for this problem, sadly with such little knowledge of your project I can only suggest some fixes
Check for any caution messages and try to fix them
This can also be caused by using #import to import an .m file, if you are using this then remove it.
Sometimes this can be caused by frameworks and libraries, If you are using an external or custom framework, you probably need to add it to the "Frameworks" folder inside the application.
Hope this helped but if it didn't I might need some more info on your project.
Go to Project file -> Build Phases and check if there ara any red icons (specially for Compile Sources or Copy Bundle Resources)
Testing any changes to my Xcode project has become an exercise in patience whenever I build. After all the source files have compiled, I get the following message in the activity window at the top of Xcode:
"Running 3 of 3 Custom Shell Scripts"
I have not added any of my own custom shell scripts but I am using quite a few dependencies via Cocoapods and I am using 2 frameworks for the build environment, Crashlytics and Tapstream. Crashlytics requires you add a run script in the build phases, other than that I don't know where the other ones are coming from and they appear to be the bottleneck in my build time.
Can anyone enlighten me as to what is going on and how i possibly speed it up?
I can't enlighten you but I can tell you how I stopped mine from running. This also happened after installing Cocoapods. In my main project's Target, under Build Phases, I noticed two entries entitled Check Pods Manifest.lock and another called Copy Pods Resources.
Under both there was an unchecked option Run script only when installing. I checked both and at least for now my projects build and run fine without running the scripts.
This is kind of a crappy answer because I can't really give you any more information, and it might not even work for your case, so hopefully someone comes along and enlightens us.
POSSIBLE EXTERNAL BUNDLE ISSUES
So I just had a frustrating experience debugging an issue where a pod installed library's NSLocalized strings file weren't working. Turns out it was because I checked the option mentioned above. Pods-resources.sh, which had the lines to install the bundle, wasn't running in debug mode. It was only running when installing - of course! Something to watch out for.
More info in this question:
NSLocalizedStringFromTable not working in CocoaPod dependency
To fix the slow "Copy pods resources" problem I figured out a solution to only copy the resources if they haven't been copied before.
For this purpose we have to patch the *-resources.sh files that are created by cocoapods such that the copy procedure only happens if a generated file in the target directory doesn't exist (it is created upon first copy). As long as this target directory exists and includes this autogenerated file, the copy resources phase is skipped. This saves me about 30 seconds in my project (of course depends on your project size). To accomplish this do the following:
Create a patch file called 'copy_pod_resources_once.patch' in your project root dir with the following contents:
5a6,13
> NONCE_FILE="${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/copyresources-done.nonce"
> if [ -f "$NONCE_FILE" ]; then
> echo "already copied resources"
> exit 0
> else
> touch "$NONCE_FILE"
> fi
>
In the Podfile for your project add the following post install hook:
post_install do |installer_representation|
system('find "./Pods/Target Support Files" -name "*-resources.sh" | xargs -I{} patch -p0 {} -i ./copy_pod_resources_once.patch')
<other post install stuff>
end
For me, it was Crashlytics. There were some outstanding changes, as Crashlytics does auto-updating of its files. I reset/removed them and rebuilt and got past it.
So the general answer may be to check any third party components and make sure they're working properly.
As Ramsel has said in this answer,
https://stackoverflow.com/a/21318086/1752988
I also went to Build Phases and cleared out all the possible links to PODs, after trying most of the other solutions and the three build issues shown regarding Pods were cleared out.
But then one file which was not list under the XCode Project navigator was missing, but they were in the Downloaded Git Zip folder! Obviously, I copied it and put into the XCode project and try running it runs cleanly! :)
I had a similar issue in my project (however not using Cocoapods). It ended up being an issue with an application external to Xcode (Spritebuilder) somehow holding onto a resource within my Xcode project when it crashed. I forced the non-xcode application to close and now the issue is gone
Check your project folder name have any space.Because space creates problem in directory path like "SRCROOT".I removed spaces and project run fine.
I've found that this happens to me frequently. Exact cause unknown, but appears to be switching between git branches that have differences in what pods are being used. In my case simply touching the Pods-xxx-Resources.sh shell script file causes it to speed back up.
Probably not going to work for you, but cleaning the project fixed it for me (Product -> Clean)
I have a project that I am managing using CMake and I have run into some very strange behavior that I don't understand. If I clear out my build directory, run cmake, run make, then run my program my program crashes every time because I fail an assertion somewhere in pthreads/boost threads. No matter how many times I make, and make clean this project it crashes every time I run it. However, if I then remove CMaketCache.txt, regenerate my makefiles, build and run, the program runs as expected every time.
In summary I need to follow the following steps for my code to work...
Run Cmake
Run Make
rm CMakeCache.txt
Run Make
Run program
It appears that the Make files before and after I remove CMakeCache.txt differ. What could explain this behavior?
Do you have git installed? If so, you can use this trick:
Run cmake
make
git add .
git commit -m ""
rm CMakeCache.txt
run make
git diff
Some odd things I can see in what you are saying. I don't see why your program would recompile anything just because you removed the CMakeCache.txt. Everything should be up-to-date from the first make, so something is bad there... My guess is that it is finding a different thread library or no thread library the second time.
I am getting the above error message randomly (so far as I can tell) on iPhone projects. Occasionally it will go away upon either:
Clean
Restart XCode
Reboot
Reinstall XCode
But sometimes it won't. When it won't the only solution I have found is to take all the source material, import it into a new project, and then redo all the connections in IB. Then I'm good until it strikes again.
Anybody have any suggestions?
[update 20091030]
I have tried building both debug and release versions, both full and lite versions. I've also tried switching the debug symbols from DWARF with external dSYM file to DWARF and to stabs. Clean builds in all formats make no differences.
Permission repairs change nothing.
Setting up a new user has no effect. Same error on the builds.
Thanks for the suggestions!
[Update 20091031]
Here's an easier and (apparently) reliable workaround. It hinges upon the discovery that the problem is linked to a target not a project
In the same project file, create a new target
Option-Drag (copy) all the files from the BAD target 'Copy Bundle Resources' folder to the NEW target 'Copy Bundle Resources' folder
Repeat (2) with 'Compile Sources' and 'Link Binary With Libraries'
Duplicate the Info.plist file for the BAD target and name it correctly for the NEW target.
Build the NEW target!
[Update 20100222]
Apparently an IDE bug, now apparently fixed, although Apple does not allow direct access to the original bug of a duplicate. I can no longer reproduce this behaviour, so hopefully it is dead, dead, dead.
Troubleshooting steps:
(1) dsymutil deals with debug information so you should probably start with the debug build. Once the problem starts can you run the release build?
(2) Create a new users and work from there to see if the problem follows. If not the problem is most likely a corrupted file in your user's directory.
(3) In my experience most linker problems are caused a permission problem somewhere. (We have to pay for security.) I would repair permissions and see if the problem goes away.
(4) In the extreme you can uninstall the dev tools from the command line:
sudo /Developer/Library/uninstall-devtools --mode=all
However, this won't help if the problem is in your user's directory. In that case, you might need to work under a new user or spend a lot of time tracking down every dev related file in the user directory.