As long as you are incrementally building your project in Carbide you should see comparable performance to VS after the initial build.

Once you import your project, then complete the first build, the IDE should provide a more robust dependancy management for all subsequent builds.

If you are seeing 25/35 min builds continuously, you may be building something outside the project that is polluting the projects dependancy files causing a complete clean build to occur after each change.

That is one caveat with Carbide, if you build any portion of your application outside of Carbide, it will pollute the dependancies tracking and force a clean build resulting in a longer build time.

Let me know if this helps. Also, feel free to send me a direct mail if you prefer.

Ronnie (ronnie.king@nokia.com)

I agree that 35 minutes is much too long, and I can see why you develop for Windows first. We have to address that, but SBSv2 alone isn’t going to do it (sorry David). If you contact me by direct email, I’ll see we can suggest some tweaks to help you right now. Even if we can’t find any way to help you immediately, it sounds as though you have a challlenging test case for the tools developers to work on.

William Roberts (williamr@symbian.org)

>It takes 2 minutes to build a Windows desktop exe of my app in Visual Studio. It takes 35 minutes to build WINSCW target of my app in Carbide c++ 2.0. Device build takes longer. This must change.

I completely agree!

Inside Symbian and Nokia there’s been a project codenamed “Raptor” and now known as SBSv2, to significantly speed up the build system. SBS = Symbian Build System. I’m not an expert at when the fruits of this project reach application developers – hopefully someone closer to the project will comment on this.

// David W.

It takes 2 minutes to build a Windows desktop exe of my app in Visual Studio.

It takes 35 minutes to build WINSCW target of my app in Carbide c++ 2.0. Device build takes longer.

This must change.

Dependency checking in Symbian tool chain is completely broken. One line change in code can result in 25 minute build in Carbide where it takes seconds in Visual Studio (when compiling for Windows).

Link phase of my application takes for ever in Carbide. Again, it takes seconds in Visual Studio.

I don’t know what Visual Studio does, but it is just so much better in every way.

I don’t care what version of GCC Symbian tool chain is using as much as I hope the compilation would be faster.

Most of my time every day gets wasted in waiting Carbide to build my application.

If I develop a new feature for the app, I work in Visual Studio and develope the feature for Windows first, because it is so unproductive to work in Carbide.

It is just beyond words how bad it is. If you have any tips how to speed up the build process, I and other developers in our company would be very happy.

There don’t appear to be any community related vacancies on the recruitment microsite (unless I am looking in the wrong place).

Is DWs “whole department” fully staffed already? It would be extremely useful (and interesting!) to know what roles exist in that area and who they have been filled by.

> N.B. Forum Nokia’s KIs are tagged with class names so matching those
> to an API or to your code at compile time should be quite easy to do.

Good news! I found that all entries now use a header template that allows for adding of keywords, but apparently not of the old ones have been tagged yet (and since the Knowledge Base is read-only, this is probably an area where the community cannot offer any help yet).

Anyway, this got me thinking, and if there was an easy way of searching for pages that include the KnowledgeBase template and contain a certain string in the “keywords” parameter, implementing such a feature would indeed be possible today, even for someone outside of Nokia.

It could, for example, come in the form of a script that annotates the reference section of an existing Eclipse SDK docs plugin with related FAQ entries, or perhaps as a mash-up of the online Developer’s Library at http://library.forum.nokia.com/ with a search of FAQ keywords…

As an aside, I just noticed that the online Developer’s Library has come along very nicely – reading results from keyword search is still a bit cumbersome because they mostly quote the “[Symbian] [Symbian Developer Library] SYMBIAN OS V9.4 Feedback [[Index]] [[Previous]] [[Next]]” header in the page summary, rather than the context in which the keyword was found, but I think I will be using this much more in the future as opposed to the local version.

>I wish that “simplifying aspects and reducing costs of Symbian Signed” means throwing all that hell out of the system. I have yet to see a non-financial reason for its existence – the users hate it, the developers around me hate it, and it’s just a weak illusion of quality or security.

For a general list of reasons in favour of a scheme akin to Symbian Signed, see my personal blog posting from last December, Symbian Signed basics.

Whatever people think about the implementation of Symbian Signed, the PlatSec version of the program has coincided with a significant drop in the instances of malware on Symbian devices – see the data in Craig Heath’s recent posting The mobile malware threat.

For these reasons, we’re not planning to discard the program. But we have serious proposals to improve it.

// David W.

>In my opinion the best people who can represent developer’s need are the people who are constantly in touch with the developer’s community on day to day basis (e.g. forums). People who discuss issues up to API level.

Agreed!

>From forum discussion and issues raised there I don’t think that voice of developers reaches to decision makers.

Up till now, that’s largely been true. The intent in the setup of the Symbian Foundation is that this will change. But, of course, it won’t change overnight.

>I hope similar participation of developer’s voice happens for SDK/API discussions as well and that was the point where I raised my doubt on Symbian Foundation. If SF can change that it will be a real achievement.

Agreed again!

// David W.

>I guess the true “launch” is when you can get your hello world app running in a simulator / device without paying for header files or the 10 year old ARM compiler.

There are several things wrong here.

First, no one has to pay for any header files.

Second, no one needs to pay for the GCC compiler. The GCC compiler can be used to compile applications (including a “hello world” app, and much much more complex ones).

Third, people can already create and build and run applications, using SDKs which are publicly available.

>I am guessing that will not happen until late 2010.

In this instance (at least), you are hopeless at guessing.

// David W.

Here you have it. There is code in the foundation, but most of it is for members only.

Thus, even when Mr Wood lifts the curtain to the public beta, you are still crippled if you don’t cough up your 1500 bucks.

I guess the true “launch” is when you can get your hello world app running in a simulator / device without paying for header files or the 10 year old ARM compiler.

I am guessing that will not happen until late 2010.

God Job Foundation and Nokia, you are really trying to make this work, not.