Recent postings in this blog have sparked some sharp commentary on the topic of Symbian developer experience. Here are a few examples:
Sebastian Brannstrom asks:
By the way David, could you write a post about the Symbian Foundation position on the state of the Symbian SDK, and what the future may hold? … the quality of the SDK leaves a bad taste in developer’s mouths.
Karl Garhen comments:
Symbian has horrible tool chain with different SDK’s and fairly weak distribution even with the great number of devices out.
And David Durant adds:
Symbian’s toolchain is frequently negatively compared to other OS equivalents. The Foundation needs to rapidly put a “tools guy” in place to start canvasing developers to the exact specifics of these issues.
To progress the discussion, I’d like to respond to these comments.
In the Symbian Foundation, we understand that the best route to significantly improve consumer experience with smart mobile devices is to significantly improve developer experience. We are commited to making it easier, more productive, and more pleasurable, for developers to create and enhance mobile applications, services, and devices.
After all, developers already have lots of good ideas for improving consumer experience. But when these developers find obstacles in their way that prevent them implementing their new ideas, they tend to slow down, lose interest, and divert their creative energies elsewhere.
For this reason, the department in the Symbian Foundation that will have the largest headcount is the department that provides all aspects of developer support. This includes people who:
- Act as community managers, spending their time in dialog with developers;
- Devise and implement initiatives to improve services and tools used by developers;
- Write and review documentation and example code;
- Work on projects to enable swifter publication of applications;
- Engage with the broader Symbian community to encourage and support others to assist with the above tasks.
So in response to the suggestion that we should rapidly put a “tools guy” in place to start canvasing developers to the exact specifics of these issues, I say this: we are putting a whole department in place.
Inevitably, it will take some time for this department to reach its full strength. We don’t expect to completely transform developer experience overnight. But momentum is building. During the last three months, the Symbian Foundation has recruited about one third of its anticipated complete headcount. We expect to double again in the next three months.
An important early outcome of the work of the first batch of Symbian Foundation employees is the new Symbian developer website. As I write these words, this site remains in an invitation-only beta. I’d love to open the site immediately, moving it from invitation-only beta to public beta. However, here are the some reasons for waiting a bit longer:
- We need to bolster the performance of the website, to avoid risks of it buckling under significantly increased strain;
- We need to complete a review of some aspects of the security of the website;
- We need to review some of the content, in cases where third party intellectual property is involved, or where there may be sensitivities about some of the information.
Our schedule remains the same as was set out as long ago as June last year – namely, that the site will be publicly accessible during the second quarter of this year.
In the meantime, projects and initiatives continue to progress. Here are a few highlights.
Reducing the number of SDKs: Rather than having lots of separate SDKs in the Symbian world – as has been the case in the past – we will move quickly towards a single main SDK. Unification of the separate UI systems is an important step in this direction.
Symbian Signed: A very constructive review meeting for Symbian Signed took place on Friday in London, attended by personnel from Sony Ericsson, Samsung, and Nokia. The meeting gave strong positive feedback on draft Symbian proposals to simplify aspects of Symbian Signed and to reduce the costs involved.
Simulator: Plans remain on track to replace, later this year, the Symbian PC-emulator (running x86 binaries) with a simulator (running ARM binaries).
Addressing other defects in SDKs: Developers have two ways to draw attention to specific defects or usability issues in SDKs:
- Share feedback on the forums on the beta Symbian Developer website;
- Formally raise issues on the Bugzilla issue tracker on that site.
Symbian Foundation personnel will keep a close eye on all aspects of the Symbian Developer website. Where needed, we will draw the attention of relevant experts (including Package Owners) to points being raised on the site.
Finally, let me comment on a remark by Kim:
[The Symbian platform is] definitely not liked by developers… Can Symbian Foundation change it? I seriously doubt it, because it is controlled by manufacturer e.g. Nokia.
I have a double disagreement with this remark:
- No one manufacturer controls the Symbian Foundation. Each manufacturer has at most one vote on the Board. Contributions are accepted according to meritocracy;
- In any case, where does the assumption come from that manufacturers will not want to improve the developer experience? All manfacturers are united by a desire to improve this experience. That message comes across loud and clear in every meeting – through both words and deeds.
33 Comments
> A very constructive review meeting for Symbian Signed took place on Friday
> in London, attended by personnel from Sony Ericsson, Samsung, and Nokia.
Is that the issue right there? The handset manufacturers, network operators, etc are well represented but who represents the variety of application level developers both large and small?
How can Symbian bring their voice to the table? Through an application developers forum / union?
> we are putting a whole department in place
Very happy to hear that. As I have said before the visible interfaces of Symbian so far seem to be targeted at the corporate members rather than developers and this needs to change very quickly while the Foundation is still playing catch-up to Apple and Google.
One thing to add to David Wood is that almost all Symbian tools will be available as open source in the Foundation. A large number of the tools packages will be EPLed straight from the beginning, which means anybody can see the source and/or contribute improvements.
Of course many developers will not have time to do this. But as a developer it will be easier to make your voice heard by engaging on the mailing lists, wikis and through raising bugs and enhancement improvements on the tools and SDKs. And it will make it more difficult to for companies and foundation staff working on tools packages to ignore your voices.
What’s the overall strategy like to take on the Apples and Googles?
Guess, some of the pain points have already been identified and are being addressed? I suppose it would also help to raise a thread on this topic and get potential developer feedback before the beta site goes live.
Too many SDKs? How did that happen? And how can the numbers be reduced? Of course not having 3 different platforms on top of Symbian OS will reduce the number of SDKs but I expect there will be as many SDKs as before (one per release + possible manufacturer specific plug-ins). Actually two per release if you count the PDK as well.
Better tools? Hopefully the simulator will be a lot faster than the emulator and at least there will be one build platform less to worry about. An update of the GCC compiler (the one shipping with the SDK is ancient) and it could be time now to switch to SBSv2. Or at least to beta test it.
As for the dialog I agree with David, the manufacturers are interested in keeping the developers happy as well. See the feedback forums on Forum Nokia, see http://tinyurl.com/SDK-feedback, see the Forum Nokia blogs where developers voice against Symbian Signed’s limitation for example.
I have a dream!
In the dream I write some code, compile it, hit F11 and it’s up and running in a emaulator/simulator that is already running and waiting to do my bidding. I find I have fixed a problem and want to make sure by debugging on a real device (not £XXXX of ref h/w but a phone the man or woman in the street has in his pocket or her handbag). In the dream, and this is where things start to become sureal, I plug the device into my PC, hit F11, then IDE askes me if I’d like to debug on the device? I say yes, hardly beliving my eyes. And, as if by magic, my app is on the phone and running and then beyond my wildest dreams the code hits a break point.
It was at this point and after I’d picked myself off the floor that this was the first time I’d used the Android SDK I realised it wasn’t a dream, but how things are in the 21st century. Shame about the h/w but feel the quality of the debugger.
I’ve been writing Symbian code for nearly 10 years and I have never got on-device debugging working reliably. Some days it just doesn’t work at all. Thank heavens for Flogger
Please, please, please make my and every over developers dream come true.
Cheers
Mark
P.S Keep up the good work. Apart from some rough edges and odditites, SymbianOS is streets ahead
Questions on the beta site:
* Does it have the code available?
* Does the code have proper logs? That is not just “importing the whole SDK to mercurial” but the logs since when that file existed.
* Can anyone file a bug report?
If any of the three is correct i’d like to have access to the site to see if the infamous select() bug is fixed.
> Write and review documentation and example code;
I believe that this in particular is one area with a lot of relatively low-hanging fruit by just consolidating a lot of the existing information in “official” sources such as the FAQ into the standard API documentation.
Speaking of dreams, one of mine is that one day in the not-too-distant future I open the documentation for RChunk::CreateLocal and get immediately pointed to the FAQ referenced in this thread:
http://discussion.forum.nokia.com/forum/showthread.php?t=93305
stating that there is a limit on 12 chunks per process in S60 3rd edition right when I decide to use it, rather than having to Google for the API call *after* seeing mysterious failures in my application.
This back-porting of FAQs, which often are “errata” and not really “frequently asked questions”, to the reference documentation has been my pet idea for some time, and I have always been surprised how many clearly inaccurate parts of API docs have been left unchanged for years even though corrections are available in Symbian/Nokia’s own publications.
I know that we can provide feedback on documentation errors through forums and , but I have yet to proof that the effort of writing feedback actually produces tangible results in the core product, rather than “whitepapering over the cracks”.
Sorry for being a bit cynical, but while I am a great fan of Symbian in general (warts, descriptors and all), ensuring that documentation correctly captures actual system behaviour in my mind seems to have slipped down the requirements list a bit too far over time.
ciao marcus
Sorry Lucian, but it’s unlikely that the simulator will be faster than the emulator. Some of the costs move to a different point in the edit/compile/debug cycle, but they are all still there, and on top of it all you have to interpret the ARM instruction set.
Good news as well though – the Symbian Foundation builds are all done with sbsv2, and I can’t see any obstacles to adopting a newer version of GCC as an alternative to the RealView compiler.
Slightly off topic, but I wonder if the tools team have looked at clang (http://clang.llvm.org/) a in-development replacement for GCC which hooks up with LLVM (http://llvm.org/) which uses a very interesting intermediate reprepresntation (human readable) and has state of the art optimisations. These tools are backed by Apple among others.
If time allows, I had thought about a weekend project to see if I can get the Symbian tool chain to use these tools.
Mark, it’s not just the Android SDK. The iPhone SDK works the exact same way, and the Visual Studios are very similar for Windows Mobile (though a little messier thanks to the feature creep). Only Symbian developers are left out of the party and love. I really hope it will change soon.
Also 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.
> A very constructive review meeting for Symbian Signed took place on Friday
> in London, attended by personnel from Sony Ericsson, Samsung, and Nokia.
>> Is that the issue right there? The handset manufacturers, network operators, >> etc are well represented but who represents the variety of application level >> developers both large and small?
This was in fact raised during the meeting that we had and everyone agreed that we need to include developers and others in these discussions. So we will be doing this in the future.
I believe LLVM is also being used as a back-end for interpreted languages like Python & Java. I wonder if it could be ported and integrated into Symbian to be a common back-end for the various runtimes?
If Mark’s suggestion of getting the developer toolchain to use it works out an extra benefit would be that you could then compile Symbian OS on Symbian OS!
@Zsolt Váradi
I gave up on iPhone development when they wanted me to send a copy of my passport!!!! Still awaiting on a refund.
@James Nash
My initial thought was to use llvm-gcc -> llvm -> .s built using a nmake/gnumake and the .s referenced from a plain .mmp.
Lars said:
> But as a developer it will be easier to make your voice heard by
> engaging on the mailing lists, wikis and through raising bugs and
> enhancement improvements on the tools and SDKs.
Of course there is a difference between people raising issues in Bugzilla and having a “tools champion” who actively canvases users for their opinions and then ensure that they are picked up by the tools development teams (as well as owning the communicating of new tools, training, etc to users). Hopefully someone in the “community department” DW mentioned will cover this.
@Mark Burton: I had EXACTLY the same experience. It was like jumping back to the “future” of software development and see that IT’S NOT MANDATORY to have to deal with ANCIENT C++ to write software for mobile.
More funny: it’s all based on Open Source/Open Standard technologies, like gdb and qemu!!!
@wtr1: Did you ever see Android running on the Emulator (because that’s what it is: WINSCW is a SIMULATOR)? And Symbian itself? I did when I was there. A guy started working on Symbian for QEMU, achieving to start th OS in a 10th of the time, if not less. Even faster than ANDROID to boot!!!
But at that time people took me as a fool for supporting this guy so strongly…
Seriously: WINSCW is “theoretically” faster but so badly written that it’s actually slower.
@David Wood: I basically agree with you, but to say that “there isn’t such a Symbian controlled by manufacturers”, it’s what I’ll call “more than just a personal and partial opinion”.
The control and the “steering” of THE manufacturer (who said “Nokia?”) was in every step that was taken in Symbian. And that was absolutely “correct”: after all Nokia owned the most of it.
Now you are “step by step” trying to change this. But the problems you are dealing today are heritage of a “not so far past”. And, as you said yourself, “it’s not going to change overnight”.
A last thought: I’m realizing that the most of those posts are focused on discussing the “technical philosophy”, “political moves”, “current market”, “business model” of Symbian but… are we ever actually going to discuss technical and more interesting stuff?
And, bear in mind, this is not a critic to the audience here, neither to the bloggers (who always arise good, important and interesting points): my critic is to make people realize that the problems of this Platform are so “deep in developers soul” and “frustrating for beeing so old complex”, that the main discuss driver is always away from the technical stuff.
For example: what about “common mistakes made by C++ developers and how symbian address and solve them” or “how to build a Client-Server architecture in 5 minutes” or “how to optimize performance of a UI-intensive application” or “how to generate JSON files in your web-based S60 app”… and I could say more.
Developers, at least of my age, want code, snippets, smart patterns and so on…
My 5 cents.
PS Please, bear in mind that WINSCW is a “SIMULATOR”, while QEMU is an “EMULATOR”, like the ARM one that Nokia preferred to QEMU… and we are still waiting here!
PPS At least this is the definition you can find on books from Tanenbaum or Sterling.
Hi David,
I think I have not articulated my statement clearly. The intention was to say that the meeting decisions are taken by Handset Manufactures and/or Network operators but who is really representing/advocating Developer’s need?
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. From forum discussion and issues raised there I don’t think that voice of developers reaches to decision makers. Any of the following may be true
a) People who interface with developers doesn’t care to raise it up to decision makers
b) People who interface with developers want to raise it to decision makers but they don’t get a chance to participate in decision making
c) People who interface with developers participate and raises developers voice and but doesn’t have power to influence decision making
d) People who interface with developers participate and raises developers voice. They also have power to influence decision making but due to some constraint can’t implement developer’s need.
e) I am completely wrong and developer’s voice have equal impact on decision making.
If e) is true I take my words back.
[[Symbian Signed: A very constructive review meeting for Symbian Signed took place on Friday in London, attended by personnel from Sony Ericsson, Samsung, and Nokia. The meeting gave strong positive feedback on draft Symbian proposals to simplify aspects of Symbian Signed and to reduce the costs involved.]]
I hope you or some other symbian foundation member were representing developer’s voice in this meeting otherwise such positive outcome was not easily possible. You must have seen that in the past that being raised this issue by developers so many time didn’t change anything.
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.
@David: as far as I remember there was a vacancy on the recruitment site.
@Kim: One of the advantages of open source is that users are brought closer to developers. As a developer who does not like the tools, I have a direct channel to the developers of those tools.
Just in case people are struggling with emulator start up speed.
If you set the executable to debugged as “epoc.exe” then while the emulator is up, you can re-compile and run your app as many times as you want from the s60 menu – you just have to train yourself never to hit “terminate” which will of course stop the emulator.
Also remember to close the app and go past any breakpoints (like malloc test dialogs) before you try and compile (or it will complain that the .exe can’t be rewritten).
It’s not great, but can save some time. So PLEEASE make that a use case for the simulator – the edit-compile-debug cycle shouldnt require a cold boot of the simulator.
I agree that the whole FAQ thing is bonkers. API documentation should have clear errata- links to sample code and an honest expression of limitations.
The documentation is describing an API’s design and intended behavior and it should do so in detail without the assumption of some things being known. A new release of the document should not be made without a review of the docs, reflecting the changes and additions.
An FAQ should not have more info that the docs on the topic, just maybe a more clear view over a particular aspect of the API. E.g. the info about the limit of 12 chunks/process should be in the API specs and not in an FAQ, unless this 12 chunks story is in fact a bug and then the issue should be documented as such and expected to be fixed.
And this brings the 3rd set of docs in the picture, the Known Issues, a dynamic collection of findings/bugs that quite possibly couldn’t be anticipated by the time the [static] API documentation is written.
Making all these things work together should be possible, either by making the docs more dynamic or by creating smarter tools. E.g. Carbide.c++ has a plug-in which, given the right database, should show you warnings at compile time about existing KI pertaining to the API used. But then again, the same can be done [more effectively] by the developer if only he/she remembers to search for FAQ/KI before taking an API into use.
@Stringer: Somehow that use case of the simulator is hidden in plain sight. Its so obvious yet you still have to explain it at some point to an otherwise presumed experienced developer.
@Lucian:
> But then again, the same can be done [more effectively] by the
> developer if only he/she remembers to search for FAQ/KI before taking
> an API into use.
This is exactly the thing that I believe a well-structure documentation should be designed to avoid, because in my view it is not effective if you are under time pressure to get an application out.
You shouldn’t have to remember to search for additional information, but be given the relevant details – I probably look up dozens of API every day when I am in the middle of a project, and searching for potential issues with each of them would probably add a significant overhead.
btw, searching the FAQ and KI lists is not always so easy if you don’t know the exact terms to search for – as an example, the FAQ entry mentioned above about the local RChunk limit would not have been found by a search for RChunk because it does not mention the name of the API, rather than the more generic term “chunk”. So how much searching do I need to do before I can be satisfied that the API will behave as described?
In respect, I fully agree with your requirement that the docs should not assume thing “being known”, and that an FAQ should not contain additional information beyond the docs.
To me, the first step would be going over the existing Symbian and Nokia FAQs, and annotating each article to make sure the names of affected APIs are explicitly written down as keywords.
ciao marcus
>> by the developer if only he/she remembers to search for FAQ/KI before taking an API into use.
That’s silly though. You can’t search every time you use a new class and what are you searching for?
You could however tag bug reports and FAQs with an API identifier – then your carbide tools/web front end could go off and list these in a tab alongside the documentation.
Here is an example from recent experience
In Java, Sun and their JSR processes end up producing a spec for J2ME and some extensions. They also produce documentation and a reference version for running in the wireless toolkit emulator.
The idea with Java is that you should be able to write once, run many. But each platform has its own bugs or limitations in their implementation.
None of these are mentioned or linked to in the general documentation.
So you can end up writing code which works on one platform but fails on another.
I don’t care how much Symbian say there will be a verification suite for the APIs. There will be bugs and obscure memory leaks etc that will leech out of the manifcurers’ implementation. I want to know all these issues up front while i’m reading the API docs.
@albert:
Yes, there is code, but most of it is still only available to members.
Yes, anyone can file a bug report.
No, the code does not have the logs all the way back to the dawn of time: the contribution is the “now”, not the complete history. It costs the contributors time (and therefore money) to prove to themselves that they own the code that they are contributing, and there is little obvious benefit to doing that for old versions of the code.
I don’t know of the “infamous select() bug”, but there are severe architectural barriers to creating something identical to the original BSD select() on the Symbian platform, so I’d guess that nothing has changed recently.
I’m not saying that you should do that before using every class, I’m saying generically, before using a new API/technology/feature. And I don’t expect that doing so will save you all the troubles but at least can show you that yes, a KI exists but a) will not affect you [much] or b) will kill your use case altogether.
To be clear, I’m not against augmenting the documentation with KIs if the technical solution is found and that KIs can be aggregated from all the possible sources.
The Java story shows my point: the specs and the KIs are two different things and as much as you would like the designer of an API cannot keep track of all implementation and update the specs each time a new bug is found. And listing the KIs would not be enough, would it? You will then ask for the specs to provide a working solution or at least a set of best practices that would help you workaround those KI …
It is my believe that Sun and the Java community want the same things you propose, it is just that they can’t get them done. Now, if SF can do this effectively for Symbian OS I will stand-up and applaud them.
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.
@wrt1
@albert
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.
@mrmr
>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.
@kim
>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.
@Zsolt
>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.
@Lucian:
> 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.
Lars said:
> @David: as far as I remember there was a vacancy on the recruitment site.
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.
I’m working on a fairly big software project that I can build on multiple platforms.
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.
@Mr. Developer
>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.
The Symbian Foundation builds only use SBSv2, but the speed advantage is mostly about enabling make to run multiple threads in parallel and make better use of the available CPUs – our Symbian^2 platform build takes ~400 minutes to do both WINSCW and ARMV5 compilation on an 16-core Windows server.
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)
@Mr. Developer
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)
One Trackback
[...] I just wrote a comment to an article I read on the Symbian Foundation blog: “Improving the developer experience“, by David Wood. [...]