Query
This question is mainly oriented to Linux distributions.
Usually there are Debug and Release builds. Will my Release build become debug build if I enable coredumps.
Reason for the query.
We are having a very weird hard to reproducible issue which gets caught only in Release build and never in Debug build. Wanted to confirm if enabling coredumps make my release build as debug build and prevent me in catching the issue ? If not i will enable coredumps in my release build to check those cases.
No. Enabling core dumps (ulimit -c unlimited; systemd uses the LimitCORE directive for this) is done prior to executing your binary, and has nothing to do with your build.
Related
I am creating linux application and want remove flutter observatory debugger and profiler from final release.
I added this on main.dart:
MaterialApp(
debugShowCheckedModeBanner: false
)
But, It's only remove banner from application.
While i try to run (release):
user#user:~/Desktop/linux/myapp/build/linux/release$./myapp
flutter: Observatory listening on http://127.0.0.1:36177/4MsXpokkp9k=/
The answer below is no longer relevant to current versions of Flutter. Release mode is now supported, so a release build will not have the observatory.
from final release
[...]
While i try to run (release)
Hopefully you saw the giant banner when you built saying that what you are building is effectively debug mode, and the documentation saying that only debug mode is currently supported for Linux. There is essentially no difference between the debug and release builds right now. You should not be attempting to make a "final release" on Linux; there's no way to do so.
It is possible to disable the observatory via engine argument. You can also disable checked mode, instead of running in checked mode (where asserts will still fire) while turning off the banner warning that you are doing so. To do both you'd add this to your main.cc:
#ifdef NDEBUG
arguments.push_back("--disable-observatory");
arguments.push_back("--disable-dart-asserts");
#endif
That still won't give you a release builds though; it'll give you a debug build with a couple of features disabled. The way to actually make a release build (which would, among other things, already have those things disabled) is to wait for release mode support.
I have a number of logic unit-tests (where my project files have a target membership of the App and AppTests). I want to add a call to xcodebuild test-without-building to my build system so that my unit-tests run for each build.
However, the tests cannot run on the release build (because release doesn't build for testing).
Is my only choice to build both the release version and the debug version during my build, so that I can use the debug version only to perform the tests? That's very different and very much worse to the other test frameworks I've used (GTest, Catch). Why can't the tests stand on their own?
The test-without-building command is not actually meant to "run the tests without rebuilding the app", but rather it's supposed to be used in tandem with the build-for-testing command.
Please refer to the "Advanced Testing and Continuous Integration" WWDC 2016 session for more info.
The gist is: use build-for-testing to build an .xctestrun file, which is then used by test-without-building to run the tests. This is particularly useful to run big suites across different machines, although I have never done it myself.
Now that we have established that you can't use test-without-building on its own, the only option to run the test from the command line and if they pass build a Release version is to use xcodebuild test, which is going to build the app.
As for the why does it need to be in Debug, I don't have a precise answer. In iOS land, at least in the teams I worked with, the difference between Debug and Release builds is always only on things like the options passed to the compiler in terms of optimization, the architectures to build on, and the type of code signing.
This means that the code that runs in Debug vs Release is exactly the same, and since we already established that you'll need to build the app twice, one to run the tests, one to generate the releasable version, running the tests in Debug seems acceptable.
I have just started using Eclipse CDT and would like to know why there are two run configurations such as Debug and Release.
Could I use this this to improve my workflow in any way? The manuals for CDT just mention that there are two default configurations, but never mention why.
Thank you for your answers.
Not specifically to Eclipse, but for all software and web development you'll encounter these two configurations.
You use Debug to test your application. You will probably generate debug symbols to step through your code, and it will probably avoid some optimizations. The purpose is to facilitate diagnosing issues.
Then, Release configuration is the one you want to use to publish or deploy your application. It could apply optimizations.
Also, if you make want to connect to different servers, or name files differently, or even execute different path codes depending if you are testing locally or if the final user is executing what you made.
Another example is Logging and Tracing, in Debug mode you may want to enable things to print to console or write to a file/log. But in Release you'll want to avoid them if it reduces the performance
I'm building a Visual Studio 2010 solution through Python with a call to subprocess. When called directly from the command line it takes devenv.com ~15 seconds to start. But when called from Python this jumps up to ~1.5 minutes.
Naturally I'm hoping to remove that dead time from our build. So I decided to test out MSBuild.exe (from .NET 4). It looks like MSBuild.exe runs instantly. But... it seems to do a full build every time and not an incremental.
The command I'm using is
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" "C:\path\to\my\project.sln" /target:build /maxcpucount:8 /property:Configuration=Release
It seems like this should support an incremental build. But I've seen posts online indicating that msbuild may not be able to support a incremental build like this.
Is this possible? If so what am I doing wrong?
Update:
I've read into this a bit more. Based on
http://msdn.microsoft.com/en-us/library/ms171483.aspx
and
http://www.digitallycreated.net/Blog/67/incremental-builds-in-msbuild-and-how-to-avoid-breaking-them
It seems like I need the Input and Output properties set in my .vcxproj files. Checking out my files these are indeed missing.
When would they be generated? Most my .vcxproj files were converted over from Visual Studio 2008. But I also generated a new project which is missing the Input and Output properties as well.
Does VS2010 not create projects with these properties?
Update: We've since upgrade to VS 2013. Now msbuild supports incremental builds. Never got to the bottom of the VS 2010 issue.
I think that fact that Incremental builds are not supported is a false Statement from according to official sources,Managed Incremental Build this feature and was included in VS2010 SP1
We first introduced the managed incremental build feature in VS2008.
In VS2010, we were not able to re-implement the managed incremental
build feature with the build system moving to MSBuild. We received
strong customer requests for this feature. As a result, we
re-implemented this feature and it is included in VS2010 SP1.
Other Solutions I found on Web
Projects should build incrementally already (just make sure that you
do Build instead of Rebuild). The best way to check if incremental
building works is to run the build from the command line. The second
time you build it should take almost no time.
If things are still getting rebuilt, then perhaps you've modified
your projects in some way that's messing up with the build order.
Looking at the build logs (via the /v option) can help you poinpoint
what's going on.
Other reason which can cause problems with the incremental build is GenerateResource.TrackFileAccess PropertyThis API supports the .NET Framework infrastructure and is not intended to be used directly from your code.
Gets or sets a switch that specifies whether we should be tracking file access patterns.
I try to automate my UI testing (using FoneMonkey ).
I have several targets, linked to different frameworks.
The issue is that I have to clean my targets before building them. If not, it looks like it loads unwanted frameworks (and thus has unexpected behavior).
So I'd like to know if there is a way to auto-clean the target(s) before building, by setting an option, using a run script...
I tried using
xcodebuild clean
But I get an
ASSERTION FAILURE in /SourceCache/DevToolsBase/DevToolsBase-1763/pbxcore/Target.subproj/PBXTarget.m:597
Any idea ?
Thanks
You can force the top level project to rebuild from scratch by removing the build directory. e.g. rm -rf build. This may be sufficient for your needs.
Otherwise, upgrade to the latest version of XCode, and failing that, submit a bug report.