I am using QTCreator 4.11 under Ubuntu 20.04.
I use am using a shadow builds for my Debug and Release builds of a project.
One of the variables in the run environment, LD_LIBRARY_PATH points to the binary folder of the build directory.
However, this doesn't play nice with the shadow build since Debug and Release are in different folders. Every time I would want to change from Debug to Release or vice versa, I'd have to go and edit that LD_LIBRARY_PATH.
Is there some way to make this process automatic?
I tried cloning the Run Configuration and having one for Debug and one for Release. However, the build doesn't appear to "remember" which run configuration it was last used with, so I'd have to remember to manually swap the Run Configuration. That's only a mild improvement.
Related
Xcode 11 has changed the way that versions are handled.
So far I had two targets, Dev & Prod, each with a separate versions. Prod version would be entirely manual, Dev would be automated:
During a build, a script would run, which then would fetch git tags. One tag would contain information about the latest Dev version. If it's newer, it would update version inside Info.plist just for the Dev target
When Dev would be deployed using a script (create an ipa, resign for in-house distribution, upload), the build version would then be increased. Remote tag containing version information would then be updated
In this way everyone's dev version would get automatically synchronized and managing multiple dev builds would be be easy. Prod would be updated relatively infrequently so it can be managed manually.
However, in Xcode 11 whenver version (or build) is updated inside the General tab, entries in Info.plist are replaced with $(CURRENT_PROJECT_VERSION) and $(MARKETING_VERSION) and Current Project Version and Marketing Version inside the build settings tab is used instead.
So far I would use PlistBuddy in order to read and update versions inside Info.plist, but from what understand now I'd have to use agvtool. However, there are two issues with it:
If it's ran as a Run Script phase, it causes the build process to cancel
It is unable to handle separate versions for two targets (so I cannot just automatically manage Dev, while leaving Prod alone)
I know that theoretically I can still use Info.plist for versioning, but the moment someone changes version manually in the General tab, the whole thing will get messed up (from experience I know that this will happen).
I have two questions:
Is my understanding of the process correct?
Can still have a version management system using agvtool similar to what I had before?
I have just proceed to update my current Eclipse Oxygen installation to the latest versions (including Oxygen.1). As I did before (with previous Neon iterations for example), I have launched Eclipse using the administrator mode on Windows.
After updating all the componants, when I restart using the normal mode, all the settings I have made in my own workspace seems to have be fully overwritten: it now looks like the default workspace.
I don't understand if I have made something wrongly or if there have been a bug during the upgrade process, but I would want to know if there is a way to retrieve my previous workspace and to prevent this kind of behaviour.
Whenever I open a new (web) project in VS 2010 the default build configuration is set to "Active (Debug)". I read somewhere that if I upload my project like this to the server it would have a slight affect on performance (is this true?), so I have to manually go to properties and change it in the build tab to release. Is there any way to tell VS 2010 to open every new project in 'release' configuration?
I believe the build configurations are listed alphabetically, and the first one is always selected when starting a new project.
Since Debug and Release configurations are always added by default, you'll always get Debug selected unfortunately.
You would be better off performing a Publish operation when you want to deploy, as this will not only build in Release (or any configuration you wish), but also will only produce the files that are required by the application. You can publish to a local folder to then upload to a remote server.
Yes, it is true that dll's built in debug mode will not perform as efficiently as dll's built in release mode. A debug mode build includes symbols to allow you to attach a debugger to the dll while it is running. The result of this is slightly larger, less performant set of libraries. However, unless you are doing some really intense mathmatical processing, you probably wouldn't notice the performance loss.
Release mode on the other hand will produce smaller, more efficient dll's but you won't be able to attach an external debugger once you have deployed your application.
I would recommend you leave your applications in debug mode while in development/test, and then before deploying to production, switch to release mode.
UPDATE: I now realize I didn't answer your original question but hopefully you find the advice useful.
I've got TeamCity installed and working, and I need to have a build step run on a particular build agent (everything's running on Windows, but we have a Mac portion I need to build as well).
How do I tell the build step what agent I want it to run on? I've seen this, but that references an entire build; I just want a particular step to run on a given agent.
Is this even possible?
From what I am aware of, it is not possible. You may want a separate build configuration to build for mac.
Sharma is somewhat correct, and KIR has it completely correct.
I needed a build configuration for each server, Mac and Windows. Then I set a snapshot dependency from the Windows build on the Mac build (to make sure the Mac version builds completely first) and a artifact dependency from the same (to copy the resulting build output from the Mac to the Windows box). Then I modified the build process on the Windows box to include the artifacts, and voila, works like a charm.
Two parts to this questions.
1) As part of our Continuous Integration build process i would like to install everything as-if it were a virgin machine. Martin folwler paper: http://martinfowler.com/articles/continuousIntegration.html
Does he mean that we take each (integration) build (clean machine) and installing ALL the necessary software to make the build work? I'm guess this is what he meant by "Single Command" build.
2) Which leads me nicely onto the next question. Is it possible to install programs using Powershell/Dos all through the command line? For example how would I install WinRar and possibly MySQL? (Winrar being a easy example, MySql complex).
Anyways, I am interested to hear from real-world practitioners of CI and how they approach their build processes.
In the latest CI environment I built, I installed and configured the toolchains and SDKs under a single directory tree and then created an ImageX WIM image of the tree. Each clean build would then mount the image, checkout sources from version control, build them, run tests etc. When unmounting, just remember to not commit the changes back to the image so that the image file stays clean.
For each of our builds with Zed we ensure a completely clean working environment, but assume that the entire tool-chain and utility applications are already installed on the machine.
If you really want to go to the level of virgin machine, then I would agree with laalto and look into VM. Setup your VM library to represent the different build environments/configurations that you will need for your product set, and load/start them on demand as you require builds for different products.
I think it is very important to always build from a clean working directory, but I'd question the real value of always trying to start with a bare OS and install everything from scratch for every build.