Background Compilation in Delphi 2010 and C++Builder 2010

Posted by on in Blogs
Both Delphi and C++ compilers now allow you to perform background compilation -- that is, you can start a compile running as a separate and parallel thread and continue working in the IDE while the compiler compiles your project.

You can continue to work in the IDE while a background compilation runs. For example, you can edit files, even the files you are compiling, and you can set and modify breakpoints.

Below a screen shot, as you can see the compiler dialog transparent during the compiler process.



Comments

  • Guest
    Mason Wheeler Tuesday, 4 August 2009

    How does that work? Seems to me that editing a file while you're compiling it is just asking for all sorts of trouble.

    Do you take a snapshot of the state of open files when you hit F9 and compile that? In that case, how do you report errors/hints/warnings properly when compilation ends if the code has changed since the snapshot was taken?

  • Guest
    Andreano Lanusse Tuesday, 4 August 2009

    Hi Mason,

    Not necessarily, big projects take sometime to compile, Delphi is faster, but in C++ take more time. During the compile process you can change the code or can just look your code, before the compile screen was modal and you have to wait the IDE just to see a single unit, now no more, of course there are some restrictions about what you can do during the background compilation, for example if you try to use code insight, change the active project and other thinks, the IDE will show a dialog asking to stop the compiler.

    All errors/hints/warnings goes the Message window like before.

  • Guest
    David Heffernan Tuesday, 4 August 2009

    Andreano,

    You didn't fully answer Mason's question. How do you deal with the race condition where the compiler wants to read a file at the same time as the user is editing and writing it?

    I guess you thought about that very obvious case and it would be interesting to know how you dealt with it.

  • Guest
    Andreano Lanusse Tuesday, 4 August 2009

    I'm sorry David, here is the answer.

    When the compiler process starts, the IDE takes a snapshot of all unit, forms and projects opened, it means the changes made during the compiler process you not be considered.


    We plan to record a video showing all IDE features, including the background compiler soon.

  • Guest
    Jolyon Smith Tuesday, 4 August 2009

    The video, when it comes, may answer the question, but the original question asked what happens if the compiler needs to report an error in a file that you have since modified.

    i.e. the compiler snapshots some unit that I continue to edit during compilation. I realise that I should have removed the body of some method declaration, having removed it from the interface, so I do so.

    The compile then faults on that method body in the snapshot, but that method body no longer exists in the source that *I* am looking at, so where does it position the context when showing the location of that compilation error?


    I have to say I can't really see the utility of being able to create such a situation. Being able to view/browse my project during compilation, yes - quite often a colleague might ask me to take a LOOK at something they have a question with while I am waiting for a compile.

    Being able to continue to make changes... no, or not so much.

    Certainly the potential for creating confusion (and complicating the housekeeping that the IDE will surely have to accomodate) wouldn't seem worth it to me.

    Why not just make all files read-only during background compilation?

    Better yet... for those who think they can live with the confusion, whilst providing a safety net for those who don't want to even RISK inadvertently stumbling into a confusing place, make it an option:

    [x] Allow editing during background compilation

    I'm guessing/hoping that background compilation is itself optional and not a new, unavoidable behaviour of the compiler.

  • Guest
    Jon Tuesday, 4 August 2009

    I'm a Delphi developer and not looking forward to this feature. I hope there is an option to turn it on/off. Making a snapshot of files in my opinion only makes the process take longer. A better solution is to lock the files and simply allow browsing.

    Btw, how do you determine which files to make snapshots of? Only the project files or including the libraries used?

  • Guest
    Andreano Lanusse Tuesday, 4 August 2009

    Hi Jon,

    Of course this is configurable and the background compilation is not on by default.

    Also, as I said the snapshot happen only for the unit, forms and project OPENED, very faster and don't take longer.

  • Guest
    Anders E. Andersen Tuesday, 4 August 2009

    Building a whole project in Delphi only takes a few seconds, so why bother with this? ;)

  • Guest
    Jan Derk Tuesday, 4 August 2009

    Nice. It is good to see Delphi starting to use multi-core processors properly. I hate freezes and waiting. Even more so if only one core is running at 100% and the other 3 are idling. Multi-core compilation would be appreciated, but I suspect that this is hard to implement.

    And I always forget to set the right breakpoint when hitting F9. Meaning I have to wait for the builder/linker to complete, go back to the IDE to set the breakpoint, then go back to the application. Now I can set a breakpoint while waiting for the compiler. Might sound like a small thing, but I do this dozens of times each day. Thanks.

    Not sure about the transparent progress window though. I don't like windows on top of my work even if they are transparent. Why not do what all modern browsers do: make a progress panel that is in the IDE *not* on top of it. And which is visible only if there is progress.

  • Guest
    Andreano Lanusse Tuesday, 4 August 2009

    Anders you are right Delphi compiler is faster, but many times you wanna look the code, the project or any other information on the IDE, now you are able to do that. For C++ developers where the compiler take more time to compile this feature will help a lot.

    See the Jan Derk example, this feature is useful to him.

    Jan, about the transparent window, you can change the IDE Options to hide the compiler dialog, doing that the compiler output will be the Message window.

  • Guest
    Brett Graffin Wednesday, 5 August 2009

    Doing anything that makes it so I don't have to pause is OK by me. Thanks EMB, I appreciate the feature. Keep them coming.

  • Guest
    Xepol Wednesday, 5 August 2009

    Very nice - what else needs to be said?

  • Guest
    daver Wednesday, 5 August 2009

    1) Great addition - have this in bcb6 and its one step closer
    2) Make the background compilation dialog smaller (consider a tray icon)
    3) Make this feature awesome by
    a) after any delay begin compilation - this starts compilation before i decide
    b) if i press run do not start a new compilation use the last one since my last edit

    This way the compiler is always compiling in dead time and I never have to wait. It will be like vb6 when I pressed F5 the form appeared instantly

    You probably guessed we use C++

  • Guest
    Luigi D. Sandon Wednesday, 5 August 2009

    Delphi is fast, but complex project groups may took a long time too, especially when building everything. Backgroudn compilation is welcome. Hope it also fixed the memory issues D2007 still has when performing a full build.

  • Guest
    Mason Wheeler Wednesday, 5 August 2009

    Jan Derk:
    Two problems with implementing multicore compilation. First off, the concept doesn't work too well with Delphi's single-pass unit model. Second, the CPU isn't the bottleneck here. Delphi's compiler can already compile source files faster than the hard disc can serve up new ones, and hard disc access is inherently serial in nature.

    We've already got the fastest compiler known to man. Making it use multiple cores won't speed it up much, if at all. The best thing you can do if you want even more speed out of it is to get an SSD.

  • Guest
    Maria Williams Wednesday, 5 August 2009

    I am all for improvement, yet lately it seems codegear is focusing on what they want to do instead of what they need to do (x64 bit COMPILER). As a record number of 64 bit equiped computers are sold each month, I hear more and more from customers how disappointed they are that we don't have a x64 compatible version of our software. I really think codegear should just focus all its energy on 64 bit support and put the "silly-who-cares-menu-improvement-and-background-compilation" stuff to the rear.... I run a real software business and need to make money to stay in business.

  • Guest
    Jon Wednesday, 5 August 2009

    daver: (3.b) your source will not be in sync with the binary that is being debugged. bye bye breakpoints...

  • Guest
    Joe White Thursday, 6 August 2009

    Mason, we have SSDs, 2.66GHz machines, 64-bit OS, 8GB of RAM, the compiler pegs one core of the CPU during both compile and link, and our Build All still takes around 6 minutes. Our automated-test project alone takes over half a minute to build. I realize multi-core compilation is a hard problem, but please don't think it's unnecessary!

  • Guest
    Mason Wheeler Thursday, 6 August 2009

    Joe, look at what I wrote again. It is unnecessary when the compiler crunches code faster than the hard drive can serve it up. That's like saying that putting a better engine in your car will make it go faster when you're stuck in rush hour traffic.

    Besides... 6 minutes? First off, that must be a huge project! The one I maintain at work compiles in a bit longer than 2 minutes for well over 3M lines of code. But if you think that's a long time, try building something that big in C++. You'll be at it all day! :P

  • Guest
    Denis PEYRAS Friday, 7 August 2009

    What about 64 bits version?
    http://edn.embarcadero.com/article/39174

  • Please login first in order for you to submit comments

Check out more tips and tricks in this development video: