I have the project which uses my second project as a lib. I see that them two has optimization level for debug none -o0 and for the release fast -0s
but in spite of this in the log, I see such a message
... was compiled with optimization - stepping may behave oddly; variables may not be available.
What are possible ways to fix it?
P.S. should be mentioned that debug doesn't work. It stops on the breakpoint, but I don't see the values of variables.
UPD
my second project - it is a lib. The structure looks like this
Demo - is a project
Lib - is lib
Let me know if I missed something
The build settings are tied to configurations. In your build settings for optimization, the Debug configuration is set to nonoptimized, and the Release configuration is set to optimized.
So far, so good.
But which configuration are you actually using when you build? That is determined by the scheme. Use the Scheme Editor to look at the schemes for your different targets. (You will have to look at them one at a time.) In each, look in the Run action. It says which configuration to use. If the pop-up says Release, change it to Debug.
Related
Eclipse is setting constantly excluded filter in build path config to **, which causes resources to be excluded from deployment. Anyone aware of this issue, and how this can be prevented? Any thoughts?
How i said in the comments of your question i did not verify any of both approaches and i only think/hope they could lead to a solution rather than i know it exactly.
First approach:
Since you handle the entire process of compilation and packaging via Maven i assume you collect required ressources with Maven only (and that if you filter out certain ressources you would do that with Maven only). In that case i would try to disable all of the eclipse filters to be included into the build path - which i would expect as the behaviour if you disable this option:
(i once experienced eclipse added a "*"Filter to my Type Filters hence i wasnt able to find anything on typesearch Ctrl+Shift+T anymore - so my hope is a similar behaviour when it comes to your filter-all-resources filter"
Second approach
Actually i think that this approach will only affect the view rather than the build/ deployment process but hey its eclipse - you just never know so i guess its worth a try:
In the following screen you should see any filters known by eclipse - i assume you will see the . Filter there as well and be able to unselect it:
I guess its worth a try - good luck ;)
I like to create slightly different code when running the app from within xCode vs when archiving in xCode.
is that possible somehow with a compiler setting that one cann access?
Just like BuildConfig.DEBUG on Android?
The recommended way to do this in Xcode is to use Schemes. They are already setup and you will see them under Edit Schemes. When you are running normally in Xcode, you are typically running the Debug Scheme, there is also a Scheme set up for "Archive" (basically a release build). Xcode supports setting up as many schemes as you like and to set one up takes only minutes.
In the example illustrated in the picture I've set a pre-processor flag "DEBUG" to be set to 1 when running the "Debug" Scheme, or debug mode in Xcode. It is NOT set in other schemes. This makes it possible to have code that is only included in Debug builds, and not included in Archive builds.
That's pretty much all it takes, then you simply do something like this in your code:
#ifdef DEBUG
<Some code that is included and executed when running the Debug Scheme>
#else
<Some other code that executes at other times in other Schemes>
#endif
This thread is very useful for finding out which files in Netbeans should go into source countrol, but it doesn't cover all files.
In particular I'm wondering whether the following files should go into source control. Here are my assumptions/guesses:
nb-configuration.xml - easiest - the file itself in the comment says it should go into source control.
nbactions.xml - from what I see this file stores information typical to running the application. I.e. JVM arguments etc. So I suppose it is a question of taste - if you want other developers to have a "suggested" Run configuration - include it. Otherwise - don't. Correct?
catalog.xml - not sure what this does (I GUESS it's used by the editor to find out xml schemas and such to enable syntax coloring, but it's just a guess). Anyway - I see that this file has system-specific information (path) - so it shouldn't go into source control.
Can anyone confirm the above?
Thanks,
Piotr
I never put my IDE configuration files in the repository, for several reasons:
other colleagues may want to use theirs;
other colleagues may want to use other IDEs (such as Eclipse) and seeing those files (or even have to exclude them from the checkout) could be annoying for them;
some of these files are generally not related to a single project, others automatically generated, so no need to store them in the source code of every project.
In order to exclude them, our first solution was the .svnignore, but it was still logically wrong to modify some shared content for the specific needs of a single user, so we decided to be more strict:
in my ~/.subversion/config I have:
[miscellany]
global-ignores = nbactions.xml nbproject
Hope this helps,
Marcello
In my Maven based projects I put nbactions.xml into source control. Just make sure to change absolute paths to relative ones.
I put nbactions.xml into source control BUT there is a caveat: it's internal format can change so if your developers, for any reason, use different versions of NetBeans you could have to remove it because sharing it becomes nasty.
Recently I upgraded from NetBeans 7.3.1 to 7.4 and the "Run" action was giving a strange error message. I solved the problem by deleting and regenerating nbactions.xml: the old one had a custom Maven goal for the "Run" and "Debug" actions; it was org.codehaus.mevenide:netbeans-deploy-plugin:1.2.4:deploy it was not visible in the IDE v7.3.1 (perhaps it has been generated by an even older version for internal usage) and was generating a class not found for org.openide.util.Lookup in v7.4. I'm documenting the problem here because I found the solution by myself after an unsuccessful search on the Net. I hope this can help someone else.
I am developing an iPhone app which uses a server somewhere to fetch its data. Somewhere in the app's source code I hardcoded the URL to use to connect to. This is fine, except that I don't always want to test using a production server! I don't want to mess with live data, just to test something locally. So I set up a local version of that same server. But in order to make the iPhone app use that server is to change the hardcoded URL in the source code.
This is a little bit of a pain in the ass to do if you're often switching between the two servers. Also, I might accidentally release the app which still uses the local URL!
I was thinking that maybe XCode can help me with this since it has the notion of a "Debug" and a "Release" configuration option to build with. So my question is: can I somehow change the Debug configuration in a way that it points to local server URL? Maybe through pointing to a properties or plist file which contains the environment specific URL. I could then make two versions of this properties file and make the debug configuration point to one, while make the release configuration point to the other.
Does anyone know how I can accomplish this?
Put this code where you need to use the configuration based on the mode (debug/release) = (development/production).
The best place to put it is on the "ProjectName"_Prefix.pch file.
#ifndef __OPTIMIZE__ // __OPTIMIZE__ is not enabled, it means that the active config is Debug, so here you have to put your code for development mode
// For example
#define SERVER_URL #"http://my.test.server/something"
#else //__OPTIMIZE__ is defined, so put here your production code
// For example
#define SERVER_URL #"http://my.production.server/something"
#endif // __OPTIMIZE__
Cheers,
VFN
In one of your header files (such as the pre-compiled header file) define macros with the URL. Take a look at this article and use a similar approach.
Incidentally, I'm using the logging approach from this article in all my apps - it works like a charm, I strongly recommend it!
You can define pre-proccessor macros in xcode by simply editing the gcc language settings:
Go to the Project menu and select "Edit Project Settings". Go to the "Build" tab .
Go to the section labeled "GCC 4.0 - Language". There is a setting named "Other C Flags". Add all the "-Dwhatever" macros you want there.
my iphone app builds fine in debug configuration, but when i change it to release, i get hundreds of errors, starting with "CoreServices/CoreServices.h: No such file or directory" in AudioFileComponent.h - part of the AudioToolbox framework.
i can't find where in the project/build settings is responsible for this.. thanks for any help.
I would recommend the following:
Open up your debug target's build settings by right-clicking on the target, hitting "Get Info", and selecting the Build tab.
Select All (Command-A) so the entire contents of the Build setting panel is selected, then copy it to the clipboard.
Paste the contents of the clipboard to an empty text document
Repeat steps 1-3 for the release target of the same project
From there you can use a diff utility or some other method to compare the contents of the two files, which will show you the settings that differ between the two configurations. Some of them will make sense (e.g., optimization settings) whereas others will not. Most likely there is a setting that differs between the two that will resolve your problem.
Another thing you can do is build one of your source files in debug mode, and in the Build Results window copy the contents of the command line to a text editor. Repeat for release mode. Then, replace each space in the command line with a newline (\r). From there you should be able to do a rough side-by-side evaluation of the differences between the two compile instructions, and may be able to figure out what's missing from that.
In general this helps you get a better feel for exactly what XCode is doing under the hood to build your project, which is a good strategy to practice no matter what tool you are using for development.
i think the problem was because i had the audiotoolbox package in the wrong place, it wasnt in system/library/frameworks like it should have been. (this doesnt explain why it built ok in debug though)