It seems all my searches to figure this out are fruitless. Knowing me it's one stupid checkbox or pulldown I'm missing. Is it maybe my install? Do I need to uninstall Xcode 4 and reinstall?
I've gone through all these steps and tricks and fixes all over the net and on SO, yet nothing gets me closer to getting an archive to pop up in my organizer. When I go to look at the archive that was built, it's just a zero k file. I get a build succeed, I change skip install to both yes and no ... I do all these things I find on the net, I'm going crazy. I'm pretty sure my certificates are all set up correctly, I have things checked where I'm told to be checked. It's driving me crazy. 99% of the solutions I see are:
"Anyway, in the "Skip Install", set the value for "Release" as "NO" (the help doc told you the opposite). Once you set it to "NO", archive again. You'll immediately see your app showing up in the archive organizer."
Well, it's not working or any further answers after aren't either.
Archive only seems to include those build products that are set to be "installed", so make sure that you deactivate Skip Install in your build settings:
Go to BuildSettings.
Find "Skip Install".
Select "NO" for Release.
Additionally, Xcode needs an Install Path. For Applications this is usually /Applications, but when e.g. building a plugin you might want to set this to just /, which will put the build product in the root of your archive. Note that you must use a "real" path, not a relative one like ~/Library.
Make sure you use Product > Archive, instead of Product > Build For > Archive.
I had this issue after I updated to High Sierra. I went to my library folder. /Users/your_user/Library/Developer/Xcode/Archives
In this folder was an empty folder named to the date I had created this archive. But the folder was empty. I removed the folder and archived again. That fixed the issue for me.
For me, I had to also change the following blank build setting, to something like...
"Installation Directory" --> /Applications
Finally, it started appearing in Organizer/Archives.
P.S. Interestingly, without this setting the old archive file was being created, but it was always empty.
I just had this issue and what resolved it for me was this:
Verify Code Signing on the release is set to your Distribution Profile. I did this and it actually reverted it at one point. Make sure that setting wasn't reverted and try again.
You mentioned the "Skip Install" value, I also had similar results. Setting to YES would not open the archive list, setting to NO would.
Hope this helps (more that #1 above helps).
Go through this checklist, and you should find an answer somewhere:
Create a new scheme labeled "[App name]-AppStore"
Create a build configuration labeled "Distribution" by duplicating release
Click the project and hit the + under build configurations in the "Info" tab.
Set the archive to build as "Distribution" under the new scheme
Verify all certificates
Verify all provisioning profiles
Verify your private key under your name in your keychain. (in the system keychain)
Make sure that in the Distribution code signing, you are setting the profile to your iPhone/iPad distribution profile in ALL signing instances.
Make sure that in your project info, the Distribution code signing is set to your iPhone/iPad distribution profile.
Make sure that you have the option, skip install, in build settings of your target set to "NO" for Distribution.
Make sure that your currently selected scheme is "[App Name]-AppStore > iOS Device"
If nothing else, clean all builds, delete all old archive attempts, build for archiving, and if there are no other errors, try archiving again. One problem that I ran into was when I let XCode always allow signing with my private key. Simply deleting that and redownloading the certificates forced XCode to re-ask me to allow code signing. I only click allow now and I haven't had that problem ever again.
If you are still having problems, you should delete all of your provisioning, revoke all of your certificates, reissue them all, and reinstall them all. Try resetting your code signing after that, and if it still doesn't work, use one of your two free TSIs given to you by Apple Dev Support. If nothing works, they can fix it for you I'm sure.
Hope this helps.
I did the following to make it work for me:
I replaced some subprojects/static libraries i had (ie three20) by using cocoapods to include the files within the main project.. it just got rid of all the trouble three20 was giving me (and they are lots..)
set skip install to yes under build settings for all other sub projects/static libraries and switched the copy headers from public to project under build phases
most importantly: under the sub libraries.. under build phases i ensured that copy files destination was changed from Absolute path to products directory.
and that was it!
hint: to get an idea of the offending files that's causing your archive to create an archive file rather than an ipa do this:
Select the archive and click the Distribute button.
Select the 'Save Built Products' option.
Hit Next and Save.
Browse the created directory in Finder.
The 'libraries' subdirectory will identify the libraries that you need to set the Skip Install to Yes.
in some cases usr/local/include will identify the culprit header files you need to move from Public to Project or the files that you have to change from absolute path to products directory. but that directory (ie usr/local/include) varies depending on your sublibrary directory structure
Related
The first step to building Qt itself is to run configure, setting up the library connections, compiler selection, etc. If the person compiling it was careful and helpful, they saved their config in a convenient, obvious location. If not, however, is there a way for me to check which args were used to configure an existing build?
If all you have are the binaries (.DLL/.so files), then "no", there is no easy way. But if you have access to the build configuration then obviously you could dig it out.
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
I have deleted my application target and now all my Build option are gone. I cannot run my project because I am missing a target. How can I regenerate it?
You have two options.
The first is DarkDust's suggestion: restore from a backup or an SCM repository if you have them. If you have neither, you must admit you were begging for trouble.
The second is unfortunate but comes with a message of hope. Recreate the target from scratch. Select File > New > New Target from the main menu and select the appropriate target type (a Cocoa Mac OS X application, doc-based, or whatever). With the new target selected, click the Build Phases tab, expand the Compile Sources phase, and drag all your implementation files - .m (and .c and .mm if you have them) - into the list so they're compiled as part of this target. Expand the Link Binary with Libraries phase and add in any frameworks you use. Expand the Copy Bundle Resources phase and drag in your resources (including xibs, credits, InfoPlist.strings, your app icon, etc.). Don't forget to recreate any Copy Files build phases you might have set up manually (if you did, you'll already know how). That should do it. The message of hope I mentioned is that you're now familiar with what a target is and all it needs to build your product. It's actually a lot simpler than it appears.
If restoring from a backup or a repository is not an option, and your bundle has many resources, I'd recommend starting a new XCode project from scratch and importing the source files and resources into it.
Create a new Xcode project of the same type and info as your project.
Delete this new project's ViewController and AppDelegate source files, copy your source files into the new project's folder, then import them into the Xcode project.
Add any frameworks you've used.
Import the resources (images, sounds, plists, etc) into the project.
It might take longer than recreating a target and adding things to it, but you're less likely to make mistakes along the way, and you'll ensure that everything is properly added to the target.
If you have version control then the following method works. I used another method to revert my changes if there are not much, executing "Git checkout ." on terminal. Changes will be reverted and Your target will be restored.
hey the title pretty much says it all. i have been trying different methods from internet sources, but whenever i try something goes wrong..this is where i got Box2D
in cMake, i get a bunch of errors when building it(i was going through the steps in the readme.txt, but onfortunately, theyre for Visual C++...)
so im wondering hot to set this up as i guess a library (.lib or .a) and use it in my project(my friend passed me his library and when i loaded it in and tried #includeing the box2D headers, they didnt read at all(i got a list of undefined errors) also his box2d was i believe made for linux/unix so i think thats the reason...)
if anyone can help provide some steps that would be nice.
thanks for reading.
Assumptions:
You have installed cmake.
You have installed Code::Blocks/MinGW to C:\codeblocks.
You have downloaded Box2D and extracted it to C:\Box2D_v2.1.2.
If any of those are wrong, modify the paths to match what you have.
Start->Run->cmd.
Navigate to the Box2D "Build" folder:
cd C:\Box2D_v2.1.2\Box2D\Build
Create the makefiles:
cmake -G "MinGW Makefiles" ..
Do it:
mingw32-make
This will throw some warnings, but should work almost completely. Then, near the end, it will error trying to compile the Testbed. AFAIK, there is no way to compile the Testbed using MinGW (you have to use Visual Studio, I believe). Luckily, an .exe of it is available on the Box2D site.
In the Box2D\Build\Box2D folder, there should now be a file called libBox2D.a. Copy this file into C:\codeblocks\mingw\lib.
Copy the Box2D\Box2D folder (the one containing Box2D.h) into C:\codeblocks\mingw\include.
[Thus, after this step, you should have a file C:\codeblocks\mingw\include\Box2D\Box2d.h, and NOT C:\codeblocks\mingw\include\Box2d.h]
And that's it. You should be able to compile and run the "Hello Box2D" example. Don't forget to link to the library.
[EDIT]
From the looks of your error, I'm going to guess that your MinGW Path environment variable is not setup correctly. Which is unusual, since when you install Code::Blocks/MinGW it usually sets it for you, I believe.
Anyway, (these steps may vary slightly depending on your version of Windows):
Right-click on "[My] Computer"-> Properties -> Advanced System Settings
Click "Environment Variables"
Depending on which Windows you have, you may see User Variables and System Variables, or it may be just one group (I can't remember the name). Anyway, create a new System Environment Variable called MINGDIR, with the value C:\codeblocks\mingw or wherever you installed it to. Then, find the variable called Path (or PATH) and append this to the end: C:\codeblocks\mingw\bin. Put a semicolon at the end of the previous entry, and do not use a space.
Also make sure that C:\CMake\bin is present in either the System Variable called Path, or the user variable called Path. If not, append it to the end.
I think that's it.
I'm using Eclipse with C++ code via linked resources on Linux. The code analysis index seems to be corrupted (Goto definition lands the cursor close to, but not on, the definition) Refreshing resources doesn't fix it, neither does restarting Eclipse.
Is there a way to flush the index and rebuild it?
Right-click on your project, go under the Index submenu, and choose either "Rebuild," "Update with modified files," or "Freshen all files."
I don't know the difference between those three options, but one of "Update with modified files" or "Freshen all files" usually fixes it for me.
Also, I'm sure you've already done this, but make sure that you're running the latest version of the Eclipse CDT. Current versions seem to have much more reliable indexing than previous versions.
From http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg10390.html, the differences between "Rebuild," "Update with modified files," or "Freshen all files":
Rebuild: Works for entire projects, only. Clears the index and indexes
the files from scratch. When cancelled it leaves you with an empty or
partial index.
Update with Modified Files: Works on a resource
selection. Checks on individual files whether the timestamp or the
scanner-config has been changed and updates the index for the changed
files.
Freshen All Files: Works on a resource selection. Updates the
selected files in the index. The index is not cleared, it is safe to
cancel the operation.
Go to your project properties -> C++ general -> Indexer.
Do this with 'project specific settings',
(or on 'Configure Workspace Settings...').
Deselect 'Enable Indexer' hit Apply.
Select 'Enable Indexer' hit Apply.
This should completely wipe out and rebuild the index.
Neither of the above worked for me (Eclipse Indigo), index still broken and refusing to rebuild properly. Until applied this one:
http://slsam2.blogspot.com/2012/02/eclipse-cdt-index-not-working.html
The crucial bit of the linked post is this:
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code.
I still wonder how Eclipse can uncontrollably shoot itself in the foot like that. I suspect that installing additional packages can trigger it. Perhaps JavaScript support in my case.
delete only the .pdom file under .metadata.plugins\org.eclipse.cdt.core helps, I got the indexer screwed after upgrading Neon.2 to Neon.3 and this seems to solve the problem.
(this comment already exists above but am not allowed to confirm it up there).
I found that I had the global indexer set to 'Use the build configuration specified in the project's indexer settings',
and the project's indexer set to NOT use project specific indexer settings.
Regardless, it was using the same fixed configuration for the indexer regardless of which configuration I had selected.
The fix:
Window-Preferences, C/C++, Indexer. Select "Use active build configuration" in section "Build configuration for the indexer".
Happy days.
Did you try adding -clean to the command line for the eclipse executable?
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code. worked for me
I started with trying Josh Kelleys and mmmmms answers without any luck, but I finally fixed it by checking my include paths.
One way to see them are in the Project Explorer, expand project and there should be an entry "Includes". Inside that, check for a small yellow warning triangle on each include path. If that triangle is present eclipse most likely doesn't recognize the path.
The include paths are edited through right-clicking on "Your project" in the Project explorer, then choose "Properties" --> C/C++ General --> Paths and Symbols --> Includes.
I see three language options, Assembly, Gnu C, Gnu C++. Choose the correct one before starting to add paths (likely Gnu C++). After adding all the paths, -->Apply --> Ok and rebuild index if you're asked to.
My erroneous workspace paths looked like MyProject/MyProject/folder when it was supposed to be MyProject/folder.
For me the "Problems"-view is always slow to update, even after rebuilding index. To be sure that the error is still there, double-click the problems entry so that eclipse opens/reloads the file in question. This often seems necessary for me to update the "Problems" view.
I don't really know if it was eclipse or my scm that messed it up. Anyway, hope it helps someone!
I use Luna and builds with an external makefile.