I'm rying to create another target under the master project. I create a target and clone another to avoid all that ugly typing. (This has worked reasonably well in the past...) Then I switch to the new target, set the target name etc.
When I try to delete the old files (from the original target) to create a new file group for the new target, I'm told that I can't delete the files, because then the file wouldn't be contained in a target. The original target builds fine, so it knows where the files are even though they aren't, apparently, in that target's file group. If I try to add the old files to the old target's file group (so the files aren't "orphaned" ), I get a gripe that everything is multiply defined. If I simply try to add the new files to the new target's new file group, I get a gripe that there are multiple main()s - one from the old target that was cloned, and one from the new target's main().
So, I'm sort of stuck using real makefiles and building programs outside the IDE, which pretty much leaves me without a debugger because I haven't figured out cross-platform dbg.
Is there a way to examine the project to find out where the targets' information is held? Can I clean this up so that the targets don't interfere with one another? Is there an easier way to do this?
Have you used the target column in the Project window, Files view, to assign/deassign files as part of the target build?
Example: if you're building two targets, A and B, you'd select target A from the Drop-down menu in the Project window. Then go the Target column (the column with the little target icon), and click in there to make the file assignment. If there's a black dot in the column, the file is part of the build. If the dot is absent, the IDE ignores that file during the build. After you've selected your files for target A, choose target B from the drop-down menu and make your file assignments with the target column. You can exclude files or share files for each target this way. HTH,
Message Edited by J2MEJediMaster on 2007-04-1311:39 AM
Thanks, Tom. That's precisely where I have the trouble. I clone TargetA to make TargetB. TargetA, in the Target column, has nothing selected - but TargetA's files are selected for TargetB.
If I try to remove the files from TargetB, I get a gripe indicating that I can't remove the file - it would otherwise not have an associated target. If I then try to add the file to TargetA so I can remove it from TargetB, TargetA complains that the file is there multiple times. Since the file appears to be there whether or not there's a dot in the Target column, I'm sort of stuck.
And the files from TargetA cannot be removed from the cloned TargetB. Doubly stuck.
The symptoms vary slightly from try to try, as I have attempted to approach this from as many angles as possible. I typically end up just copying back an archive of the project file to recover.
I suspect that the project file has become corrupted over time, either due to a bug in the IDE or some corruption from source control, but in any event, it's apparently impossible to add targets to it in its current state, which leaves me no option but to write Makefiles and use make, which makes debugging difficult.
That is a problem if that target feature doesn't work. The only thing I can suggest is:
1) Make a copy of the project's directory (that is, the directory enclosing the project file, its source files and all of the supporting files/sub-directories. 2) In the duplicate directory, delete the _Data directory. That is, if your project is named junk, with junk.mcp, delete the folder junk_Data. 3) Now launch the IDE. Issue the following commands: Project | Remove Object Code... Project | Re-search for File Project | Reset Project Entry Paths This, along with deletng the _Data folder, are as close as you can get to a complete lobotomy of the project without losing all of your settings. 4) See if the target column works now.
Since you're working with a copy, if that doesn't work, you can fall back on your original.
The only other course of action is that you start with a new project, add your files, and modify your settings. If it is a corrupted project file, that will clear the problem. Yeah, right, it's a pain in the posterior doing that all over, but it can't be any worse than writing build scripts.
Do I correctly infer that I need not save the .tdt files in source control? Not that a lot of my time is spent locking and checking in these files, but anything we can do to make John's life easier, you know?