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.
Related
We have a team of several members using Eclipse for a C & C++ application that we commit the make files it generates as part of the package build. I have added and committed a library to the project then we decide against using it. So I remove it from my project and commit the change to git for the rest of the team. When anyone else pulls the change their Eclipse reverts the removal to the .cproject file preventing the removal of the unwanted library, include paths, and toolchain paths. The only thing that seems to work is to blow away the project metadata and re-import the project, which is a hassle.
How do I easily get everyone else's Eclipse to accept the removal and stop adding it back in?
Thanks.
The issue comes from not committing the .metadata folder. Eclipse keeps a backup of the project somewhere in there and continually changes these file making it unreasonable to commit to source control.
The only thing I've found to always work is to delete the project from the workspace, but do not remove the files, and import the updated project after pulling the updates from source control.
You and your team may not be able or willing to do this, but it is easier to not check in IDE specific files at all and allow a build tool plugin like Maven or Gradle to handle the project structure and classpath. This is how I've worked with team members for years without experiencing this problem.
There is quite a bit of a paradigm shift doing this, and depending on the flexibility of your project it may not be feasible.
Edit:
I noticed you are of the C persuasion. I don't recommend Maven, but consider Gradle.
https://docs.gradle.org/3.5/userguide/native_software.html
I have an interesting configuration I might be going completely wrong about.
I have a solution that has it's own project, and another two projects that are loaded from two separate submodules of the repository.
I use those projects to build two libraries I use for my own project and then use the pre-build event of the main project to copy freshly built .dlls to the output folder of my project.
However, I've come to a snag. One of the submodule projects is using multi-byte character set, while the other one uses unicode character set.
I can change the character set of my own project, but I cannot change anything within the submodules since I'm changing just my local copy - anyone else who clones the repository would still get the unchanged version.
Is there a way I can somehow edit the project properties via some sort of pre-built event of another project, or something similar?
Doing it this way ensures that anyone who tries to modify project has the .dll version compiled on their own machine. Is that worth the effort or am I just over-complicating things? Should I just compile the libraries and then add the compiled .dlls to my project and leave the submodules out of it?
Historical context:
We have a project consisting of following parts:
Host application (C++)
Scripting Engine library (also written in C++)
A lot of C++ plugins (around 30+)
A lot of scripts that tie all the stuff together...
From version to version some plugins are added and some are removed.
Till now we used Visual Studio solution (*.sln) to contain all the projects (*.vcxproj) for Host application, Scripting Engine library and plugins (one *.vcxproj per plugin!).
To share sources/projects we use proprietary source control system, and till now once we merged updates from the server (some plugin projects are added and some plugin projects are removed) all the project tree in the VS were refreshed thanks to "reload" feature (no action was required from developer to see and build updated source tree).
The problem:
Now our senior management decided to switch to Eclipse CDT/MinGW pair and we faced the issue that Eclipse Workspace is not the same thing as Visual Studio *.sln ...
Now when some plugin project folder appears or some plugin project folders disappears corresponding workspace items do not update accordingly.
Thus from now every developer has to use File>Import...>General>"Existing projects into workspace" File/"Open Projects from File System" to add new projects to own Workspace manually once they were added by other developer to the source control.
Also one has to manually remove from own Workspace those plugin projects that were deleted from source control...
This is a great contrast with what we previously had with Visual Studio where "reload" feature automatically updated project/source tree (just bacause all the information arrived with *.sln/*.vcxproj from server).
Our first option was to place Workspace\.metadata etc stuff to source control (as we previously did for *.sln files) but "that is not the way how Eclipse Workspace is designed to be used" (this is even not possible just because paths in .metadata\* are absolute and tons of Workspace\* stuff it is not mergeable at all)
Question:
Is there some way to automatically syncronize Eclipse CDT Workspace with project set obtained from source control. Like just press some (hidden?) magic "refresh" button (in special plugin to install or something like that) and all the new projects will be automatically added to the source tree in the Workspace and deleted projects will also disappear automatically, wothout need to use all those "Import" wizards, and withot need to remove deleted projects manually?
May be there is a special "Container" project type in Eclipse to play the same role as *.sln did in Visual Studio or something like that?
May be other options available?... Overall intention is not in replacing *.sln by some Eclipse equivalent but to support similar workflow when bunch of plugin projects is managed as a whole and project set "refresh" to be simple operation that does not require from each person in the team to manually track projects appeared/disappeared in that set.
Have you looked at using CMake to generate the Eclipse project files? You can then import those into an Eclipse workspace.
Its not automatic, but if you create separate CMakeLists.txt files for each part, then you can easily comment the include of that part in the main CMakeLists.txt file and regenerate the project files when you only want to load subset of the project.
https://cmake.org/Wiki/Eclipse_CDT4_Generator
Should you ever want to change back to VS or to another IDE CMake can generate project files for that too.
I've personally only used CMake to generate VS-solutions and Unix make files so I can't vouch for how well this works.
HTH.
On side note, why did management decide that Eclipse should be used instead of Visual Studio? It sounds like a poor decision without factual grounds or impact research prior to the decision being made.
Was it because Eclipse is free? Did they consider what reduced developer productivity costs?
So, we are in this process of migrating XAML Builds to vNext (2015) Builds on TFS, and we are trying to "do things as clean as possible", since we had many, many customizations on the XAML builds that could be avoided and actually gave us problems along the way.
One major issue we are facing is with paths and "global files". Let me explain:
There are some files that, for commodity reasons, we have on a single place and every SLN file on that Collection refers them. Those files are such ones as Code Analysis RuleSets, Signing Files (SNK), etc. So the change is made in one place only and it affects every build.
Well, in XAML Builds we have a Build that runs with CI that downloads (Gets) those files, and since we hammered-in the same exact pathing for TFS and Machine (with a environment variable for the beginning of the path), the path is the same on the Developers and Build machines. However, this creates dependencies between builds and workspace issues.
My question here is, is there a configuration that I am missing that allows referring to files in other branches other than the build one? Since I’m trying to keep the build machines as “disposable” as possible, it’s running with an Agent Config Out of the Box: No custom paths, no hardwiring.
I already tried referring the files directly with their source control path, for example. The only options I’m seeing are either creating a PowerShell/CMD Script that downloads those files right into the same folder as the SLN or keeping it “as it is” and use relative paths putting a “Build” Build Step before the actual Build Step so it downloads the files to the server.
Isn’t there an “Elegant” way of doing this? Or is our methodology wrong from the get go?
You can add a Copy Files step to copy the files that the build needs:
Recently I needed to create a deployment package for my Qt-QML application. This process is quite tedious, as you need to manually find and copy dependencies. As described in (official?) Qt Wiki:
Copy the following into C:\Deployment\
- The release version of MyApp.exe
- All the .dll files from C:\Qt\5.2.1\mingw48_32\bin\
- All the folders from C:\Qt\5.2.1\mingw48_32\plugins\ (If you used QML)
- All the folders from C:\Qt\5.2.1\mingw48_32\qml\
Do the deletion steps below in C:\Deployment\ and all of its subdirectories.
After each deletion, launch C:\Deployment\MyApp.exe and test it.
If it stops working, restore the files you just deleted.
- Launch MyApp.exe. While it is running, try to delete all DLLs.
The DLLs that aren't used will go to the recycle bin,
leaving behind only the DLLs that you need.
(This trick doesn't work for .qml and qmldir files, however).
- (If you used QML) Delete a few .qml files and try relaunching MyApp.exe.
Repeat until you try all .qml files.
- (If you used QML) Delete qmldir files from the folders that have no more DLLs or .qml files
For any modern tool such procedure looks completely ridiculous. Yes, I know about windeployqt.exe, but it doesn't find all the .dll dependencies and does not help at all with .qml dependencies.
Is anyone aware of more practical approaches to this problem, how do people deal with this in big projects? Are there any tools that could help?
Are Qt developers planning to do something about it?
For windeployqt there is the option --qmldir.
windeployqt --qmldir f:\myApp\sources f:\build-myApp\myApp.exe
So it checks also the import and fetches the qml dlls too.
All of this is described in the linked article