I have made two targets in my project. One for a Staging version and one for a Release version. This way I control the different setting that goes into each build.
(different version, different identifier, different URL schemes etc.)
Everything in the (with the appropriate target selected) "Build Settings" tab behaves nicely and does not change. The things in the "Summary" and "Info" tabs, however does not persist between building/running the app.
If I go to the Staging Target and enter a version number, then to the Release Target and enter a different number everything is fine at first. When I Run the project, however, the values gets "synchronized". So if I run the Scheme that uses the Release Target it will set Release Target values on the Staging and vice versa.
In my understanding the targets inherits their values from the Project Settings, but I am pretty sure they should not inherit from each other, which would defy the point of targets.
Is there somewhere I have linked the two or ticked a wrong checkbox?
Thanks for any help given.
The problem turned out to be that the apps app-info.plist file took precedense over the target settings. This meant that settings/values that were in both the target setting and the app-info.plist file would end up selecting the app-info.plist values at compile time.
The solution is to make an individual info.plist file for each target.
I now have app-info-staging.plist and app-info-release.plist - each with the values specific for the target. Doing it like this makes the target plist file take precedense over the app-info.plist file.
You should check the Build Configuration of the different stages of you Build in the Schemes you are using. Maybe they aren't set correctly.
Related
I have an openembedded build for some custom hardware that has a BSP layer. When I build, BSP layer throws an error because the size of one of the file systems is too large. I found this issue in my (names deliberately changed)
meta-my-bsp/conf/machine/machineA.conf
In machineA.conf, there's a line:
require conf/machine/include/machineA.inc
In machineA.inc is the value I need to change to resize my filesystem to make it the right size. When I edit this directly in the meta-my-bsp layer, this compiles and creates the filesystem correctly.
Now, I need to put it into meta-my-layer which is has a higher value than the BSP layer (overrides the BSP layer recipes). So I copied the files into my layer.
meta-my-layer/conf/machine/include/machineA.inc <--- Modified with the value I need
meta-my-layer/conf/machine/machineA.conf (No modifications)
However, when I rebuild everything, it doesn't look like my machineA.inc is getting picked up. Is this the right way to go about it, or am I missing something? I can pull in the whole meta-my-bsp conf and recipes into meta-my-layer, but that seems totally overkill and a bad design. What is the proper way to override this configuration?
To use the machineA.inc from meta-my-layer you should do
require ${COREBASE}/meta-my-layer/conf/machine/include/machineA.inc
Is it possible to compare two versions of a compiled ASP.NET application (V2, Webforms). When I say compiled I mean all the code is in separate Webform and Codebehind DLLs in the "bin" folder ie the "Use fixed naming and single page assemblies" publish option in VS.
Currently I used "Beyond Compare" to compare "Source" and it does an excellent job of this especially as one can compare 2 folders and it will go away and compare all the child folders and files. Unfortunately I have not found a way to compare a "compiled"/"published" application with it.
Thoughts?
Many thanks.
You can compare binary files from Beyond Compare. Just do a folder compare and when you have your folders selected, select the files you want to compare and hit the Compare Contents button to display the dialog below:
When you hit start, it will compare each file and tell you if they are the same or not. File that have this icon between them are not the same as each other.
If you're trying to find a way to compare the DLLs, take a look at the Reflector Diff AddIn.
This article offers a few other options as well.
Let's say that I want all my programs under a flex project to go to a new url, with the name of the program's html and swf as variables. Now, normally, it's going to hardcode Foo.mxml to a URL of:
file:///local/wherever/project/bin-debug/Foo.html
But I want it to go to:
http://localhost/elsewhere/?a=Foo.html?b=Foo.swf
Now, I can do this in a hardcoded way by editing Foo.mxml to be the above, but then I have to do the same for Bar.mxml and Baz.mxml. I really want to be able to do (something like) this:
http://localhost/elsewhere/?a=${html}&b=${swf}
And have it fill in the result for me. Then either set that as "the default" somehow, or at least make just one run-debug-setting and reuse it as needed. Any thoughts?
Update:
To clarify, the point isn't specifically to pass in "a" and "b" - yes I can use flash variables or other things. The issue is that I want my own "default" setting that takes the name of the project into account, because the default 'file:///' URL is not appropriate.
Also, yes, I'm using Flex Builder 4.
Are you using Flash Builder? The Command line tools? Or some other IDE?
In Flash Builder, you need to create a 'run' profile for each main application file. I'm not sure how to apply Macros / Variables in that situation. It is a one to one relationship between application and the run profile.
You can use some variables in the HTML template files, though, but off the top of my head I don't i know the complete list of the ones available [and couldn't find a list in Adobe documentation].
Pass them in as Flash vars.
I have two dynamic views in ClearCase which, as far as I know, are supposed to be "equal".
One is supposed to look at the "Main branch" and one at some other branch (let's call it A).
I did a merge from A to Main (in the Main view) and for some reason the code at the A view compiles while Main does not.
Is there a way to compare the views for differences?
The simplest way is to use an external diff tool on those two views (like WinMerge or BeyondCompare on Windows, KDiff3 on Unix or Windows, ...).
I would actually create two new views (with the same config spec than the two initial views), to remove any "cache" effect, and start the comparison there.
Once that initial examen is done, I would start the compilation in those two views, and see if one of them still don't compile.
Don't forget that merging A to Main will not always result in the same set of files after the Merge.
It would be the same only if no evolution has taken place in Main since A started (or since the last merge from A to Main).
The setcs -current you mention will:
–cur/rent
causes the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
If you depend within your config spec on an "include file" which was at the wrong version, the first setcs would set it at the right version, and the second one would read its content and set the right version for the rest.
My organization builds a C++ application that runs on multiple operating systems.
Should the build number, visible to customer, be the same for a given state of the source code tree on all the platforms?
Yes, I think so.
One practice you can use is to use the changelist number or however your source control system identifies the checkin that your build system pulled to build your product. That way you always know what source you should pull to rebuild it as well.
There aren't any downsides that I can see. You want to be able to reproduce the build, so each should say what the build is. If it's the same build, it should be the same build number.
If you choose to (or cannot - from a build process point of view) not use the exact same versionnumber for builds made for different platforms, you should document exactly what your versionnumbers actually imply.
If you don't, typically a user of the software will treat the whole thing (e.g. 3.1.0.333 - where 333 would be the build number) as identifying a certain version of the software (thuse the code tree). If they use your software on differnt platforms, they then might think that 3.1.0.333 and 3.1.0.334 are actually refering differnt versions (as in code changes) of the product, which they might not.
The same is true for outher "build number" styles, like using some sort of date/time derived build-id.
If you globally manage your build numbers, you might consider adding a platform ID. So that you can build 3.1.0.333-x86 and 3.1.0.333-amd64 one after the other, but still have them share the same "number". It will also be more obvious to the user what the indent/meaning is.