Every time I create a new project in Delphi 2009, it loads up two sets of build settings: Debug and Release. Problem is, the Debug settings are all wrong. It has optimizations on, which makes the debugger lose local variables, and Debug DCUs off, which keeps me from tracing into the VCL.
Is there any way to edit the original template so I don't have to keep changing those two settings every time I create a new project?
Set up the Debug configuration you want using Project|Options, and then check the "Default" button at the lower left of that dialog before saving your changes. That makes those settings the default ones for all new projects.
Note that checking the Default button will not affect existing projects; it only affects new projects you create from that point on.
Related
I have two VS2013 sessions opened, each with a solution that is version controlled by the same visualstudio.com TFS repository.
In one project I wanted to check in some files, but Check In will always want to check in changed files from all my other VS projects.
Is there a way to make Check In work only on the current project?
It's very confusing when checking in project A also checks in project B when I am not ready or certain about the state of project B.
Check ins are based on your workspace, not the solution or project you are working on, which means a check in will always detect changes made in any of the folders that have been mapped from source control, regardless of which instance of Visual Studio they were made in (since it looks at the physical disk to determine what changed).
You can be more specific about your workspace mappings and/or use multiple workspaces if you wish to have a smaller scope for your check ins, though this brings with it usability complexity as you now need to ensure source control explorer and pending changes are referring to the correct workspace.
If instead of checking in with no scope (defaults to workspace wide) you can right click on the scope you want.
If you right click on the solution and select check in, Visual Studio will filter the checkin for you. It will be scoped to only files in that solution.
Whenever this happens to me, if I have made changes in the VS instance i do not want to check in, then navigate back to the one i want to check in, I am presented with an alert box that says something like "the files have changed, would you like to update them?" If this is true for you, you could just say no.
Alternatively, if the each VS instance is touching code in different branches, then you may choose to "exclude" (in team explorer) these other-branchly files.
How can I make Xcode automatically build when I save changes to a file?
I may have to stop developing for apple if I need to hit that stupid play button/ reach for a mouse one more time.
I am so desperate that I have even considered using Java.robots to click the screen for me on git commits
Look at Jenkins - This does exactly what you want. It's a bit of a faff to get it set up the first time, but it will save you hours in the long term.
You can build without running by hitting (CMD+B) by default. The default behavior of the IDE is to save modified files upon build, so if you just want to save and build all the time, just hit build, and it will do both for you.
You can even modify the shortcut key for build to be cmd+s if you really want to by opening up XCode preferences (Cmd+, by default, or going to the "XCode" menu in the top left and selecting preferences), and go to the keybindings section and change the "Build" action keybinding to be cmd+s
I am unable to figure out how to change default build/compile settings. The little default checkbox in the lower left of the project options dialog is gone. The documentation states:
The Default checkbox that appeared at the lower edge of many Project Options pages has been removed from the product. If you want to specify options as the default for multiple projects, the suggested alternative is to use option sets instead.
I'm going round and round about "Options Sets", "Configuration Manager" etc.. Is this even possible? What does "specifying options as the default for multiple projects" mean? If I have multiple projects then that means those projects and their options exists, how can I set a default value to something already set? What about new projects?
That feature really has gone and there is nothing like it any more in the product, to the very best of my knowledge. I think the best you can do is as follows:
Create a new project.
Change the project settings to whatever you want them to be.
Change anything else in the default project that you don't like, for example { Private declarations }.
Add this project to the repository.
use File | New | Customize to move this project template onto the File | New menu for easy access.
Project->Options->Target. You can set up a base configuration, and then provide different options that differ from the base for Debug and Release. You can also create custom option sets, which means that they're different from the standard Debug and Release. You can also have different configurations based on different targets (VCL app's Debug build has different options than a FMX app's Debug build, etc.)
To change the default options first starts with defining "default". You can start as low as the "base configuration" through Project->Options->Delphi Compiler, and then choosing the All Configuration target. You can refine it somewhat by altering the base configuration for the Debug and Release configurations. You can also define your own option sets, using the Save button next to the Target list.
Your specific question about "specifying options as the default for multiple projects" means is the base configuration. From there, you refine those base options to give you debug settings and release settings (which can also be saved as your initial defaults, and refined on a per-project basis).
So, for a specific answer, you can change the default by modifying the base configuration, or by getting more specific by modifying the debug or release configurations that inherit from that base, depending on what your end result needs to be and what you're trying to accomplish.
I have a complex project group that has about 10 "final" build configurations configured in a tree, where each node has its own option set. Something like this:
Base
Release
Release Generic 1
Release Final 1
...
Release final 5
Release Generic 2
Release Final 6
...
Debug
same as release, but for debug
so, all base, Release, Release Generic X, Release Final Y have their own option set saved in files and added as reference. So you will have
base.optset
Release.optset
Release Generic 1.optset
Release Final 1.optset
..
The main differences between these option sets are various compiler defines enabling/disabling certain features that are organized in the tree mentioned above (hence the build targets and the option sets) and obviously search paths that include the needed stuff.
So each option set also contains different search paths that depend on the respective build configuration.
There are over 100 projects in the project group and most of them relate to one another on different level of configurations, so there are also a bunch of Build Groups, but this is irrelevant for the question as right now I'm trying to build the projects one at a time.
The problem is that every option set is configuring the search path. Up to and including "Release Generic 1.optset" the search path is correctly updated and used. However, the "Release Final 1" and siblings don't get the search paths introduced by "Release Final 1.optset". (I know this because I looked at the compiler messages and checked the parameters passed to dcc32) It appears like the option set is ignored.
Everything is configured with "inherit=true" in the option set.
There is nothing specific in the build configurations, nowhere. Every project uses the configuration in the IDE and option set files only.
Is this issue/limitation documented anywhere/known about? Is there a workaround? Other than applying the option set as value and not by reference.
Thanks.
later edit:
I decided to implement a pretty ugly workaround in order to get moving: basically, replicate teh configuration from "Release Generic 1.optset" into each "Release Final ?.optset"
this has the major disadvantage of having to edit 5 option set files propagating the same modification, when in need of adding something to "Release Generic 1.optset"
Finally I managed to figure out the problem. It's actually a bug in the Delphi IDE in that it messes up the imports in the dproj file.
Specifically, if an optionset is added once, it will not be maintained with the necessary import condition for the rest of the configs.
This usually happens when you add/delete a configuration, the dproj gets busted and optset files no longer get imported for all the configs.
But once your configs are stable and you no longer change them, the dproj remains stable.
I mocked up an application to validate dproj files against these issues, verifying that each config has its optset files in an import directive. I'm yet to make it auto-correct this, as I'm rather busy. But once I manage to find the time, or if there are more people affected by it and require an automatic fix, I'll try to make a release.
Until then, if you noticed the option set is not applied for a specific config, simply find the configs id in dproj (something like Cfg_10 ) and see if you can find an
<Import Condition="'$(Cfg_10)'!='' And Exists('optset file path name')" Project="optio file path name"/>
if not, then add it after the other <import calls
I am working on a Visual Studio 2008 project that is already added to TFS server.
I am not sure which settings and policies have been configured for the TFS (this is done by a separate dept, not developers)
Every time I make an edit to a code file , the file is checked out automatically (without explicitly checking out the code file myself)
Please help me locate this setting or policy because it is not very useful at the moment. Sometime you want to make a local change to try out something, and not necessarily check out the code....
It is in Options\SourceControl\Environment
Checked out Items: Check out automatically
change it to
Checked out Items: Prompt for exclusive checkouts
or your preferred action.
Unfortunately, with TFS it puts read-only locks on your files to PREVENT you from editing the file without checking it out first.
I cannot stand this decision. What you'll have to do is allow TFS to check out the file, then "Undo checkout" on it later if you don't want to check it out.
Make sure you have shared checkout enabled, exclusively locking files is the path to madness. ;)
I think this is a feature not a problem. If you change a module and it's under source control, you are now "out of sync" with the repository. If you exit (and the default behavior is to save) - and come back later - the file is not what everyone else is seeing. This can be dangerous.
For example: back in the days of VSS - on a Friday afternoon I had to "put out a fire" and debug a problem in, Prod Environment, so I changed the connection string in the appropriate config file. Another developer had the file checked out - so I did the usual workaround to mark the file read-only so I could save it. I figured out the problem and informed the user. This was in fire-fighting mode - so I didn't consider the fact that I now have production connection string in my dev configuration.
Monday mornign I come in and open up the solution. Is there any feedback telling me the config file is pointing to production? No I have to remember.
If the file is checked-out however - that icon is indicator to me that "flags" the fact that the files have been modified. I don't quite understand the "big deal" in having to right-click the solution and say "un-do pending changes"
Or if you want to save them, as the down-voted suggestion by aleichtle.wordpress (I don't understand the down votes - I think it is an excellent suggestion) explains, you can shelve the changes. This will remove the check-out and also save the changes on the server.
Version Control systems are a critical and important component of the software development life cycle. It is important to consider your "process". You may need to make adjustments as you use a different tool ("When in Rome"....)
It may be difficult to make the adjustment - but there are often good reasons the tool works the way it does.
You can make a shelveset of the code allowing you to make a change to the code without affecting the rest of the development.
You can do this by right clicking on the file and selecting shelve pending changes.
I'm running Windows 7 and VS 2010.
From Windows Explorer, you can
- right-click on your project's main folder
- Choose Team Foundation Server
- Choose Workspace
- Remove the active Working Folder (bottom of the screen).
I belive this removes the bindings to TFS, and you're free to wreak havoc on your code at will.
Close your solution.
Unplug your network cable.
Open your solution.
Visual Studio will tell you that TFS is not available and will open the solution "Offline".
Plug your network cable back in. VS should not take the solution "Online" until you explicitly ask it to.
You can then make any changes you like. When you attempt to save files it will tell you they are readonly - just overwrite them.
If you decide you want to check them in, take the solution Online by right-clicking it in the Solution Explorer.
Otherwise, just delete the local copy of the source when you're through with it.
You can remove binding to source control from file menu.