Here in Aotearoa there is a beer company called “Tui”, named in turn for a native bird. As well as a series of TV ads voiced by the great Tom Baker, Tui are famous here for their “Yeah, right!” billboard ads.
I felt compelled to make one for Delphi.
I am currently working on preparing a whole bunch of stuff for (long overdue) release. As part of that exercise I have set up as many IDE environments that I can and intend to support. This means Delphi 7 thru XE5.
Along the way I’ve had to ensure that my code remains portable (and sensible) across the “Unicode Divide” and deal with changes necessitated by the addition of newly supported platforms.
One hiccup occurred when I found that Delphi 2009 did not support nested use of environment variables.
This meant that my practice of setting up IDE’s with environment variables to identify key paths which are themselves derived from a single key point, for example these are some from my Delphi 2010 settings:
| Variable | Path |
|---|---|
| DCU | c:\dev\dcu\d2010 |
| SRC | \\psf\home\etcetc |
| DELTICS | $(SRC)\libs |
| FASTMM | $(SRC)\vendor\fastmm |
Build products such as DCU’s and BPL’s are output to locations within my VM guest machine, but I keep my source tree in a location separate from and independent of any VM.
If I ever need or choose to relocate my source tree I can update my IDE(s) with a change to a single environment variable.
Not in Delphi 2009.
This all works well in Delphi 2007 (and Delphi 7 for that matter) and 2010 (and XE, XE2 etc) but in 2009, environment variables within environment variables are not resolved.
Fortunately (it turns out) I decided to maintain these environment variables within the IDE itself, partly out of habit (it’s where I first defined them) and partly for the more pertinent reason that some of them are IDE specific (the DCU path, for example). So fixing this problem was relatively simple. I just had to avoid using nested environment variables in these settings for the Delphi 2009 IDE.
So what’s the big deal ? This is ancient history. There was a problem, it was fixed. This isn’t really relevant now, right ?
Wrong.
From XE2 onwards there is the issue of platforms, which impacts my DCU environment variable:
| Variable | Path |
|---|---|
| DCU | c:\dev\dcu\xe2\$(platform)\$(config) |
This sadly does not work in XE2.
When you build a project with the Output Directory set to $(dcu), the IDE creates:
c:\dev\dcu\xe2\%platform%\%config%
This doesn’t appear to be the same problem as in Delphi 2009 since my variables that rely on nested references do still work OK. It appears to be the $(Platform) and $(Config) variables (and perhaps some other IDE defined ones) that are the problem in this case.
NOTE: XE2 Update 2 was used to this point. As I write up this post I am uninstalling XE2 so that I can install “update” 4. All part of the joy that is being a Delphi user these days. Whether the bug remains in Update 4 I have yet to discover.
But even so, you would have thought that having faltered once in this area, closer attention would be paid to making sure that the same or similar mistakes are not made again. Certainly this is the way we go about our development changes.
“Learning from our mistakes”, I think it is called.
At least in XE4 the IDE behaves correctly (I have not yet got around to setting up an XE3 environment) and will create and use a folder corresponding to the currently selected platform and configuration set for the project, so for a Debug build for Win32:
c:\dev\dcu\xe2\Win32\Debug
So what’s the big deal ? This is ancient history. There was a problem, it was fixed. This isn’t really relevant now, right ?
Wrong.
Yes, it was fixed in XE4.
But whatever Embarcadero were busy doing for XE5, leaving well enough alone in the area of “Things that were Broken But Have Now Been Fixed” wasn’t one of them, because this bug has regressed.
Which would be bad enough if it were the first time that they have gone backwards in this specific area.
I also have to say that even in the short time spent with it so far I have found XE5 to be one of the most unreliable Delphi IDE’s of recent years. I am lucky if I can open/close more than two or three projects before triggering a never ending cascade of exceptions in various ide/rtl runtime packages. And no, I don’t have any 3rd party packages, experts or components installed (or any of my own).
Fortunately, I didn’t pay for XE5 myself, having access to it through a license provided by my employer. If I had I would be angry as well as frustrated.
As it is, fortunately/unfortunately – depending on how you look at it – I only/still have to deal with the frustration part.
Oh, and as for the specific problem with platform and configuration specific DCU output directories, I haven’t yet come up with an elegant solution.
The best I can think of is to have separate configuration sets for each combination I need (that’s four: Win32 Debug/Release and Win64 Debug/Release. You will have more if you are trying to use Delphi to create FireMonkey games apps for OS X, iOS and so-called “Android” support) with explicit variations in the DCU output directory setting in every single project.
Oh, and remembering to select the Configuration appropriate to the selected Platform as well as selecting the Platform itself, of course.
Does anyone have any better ideas, short of simply doing a full build on every project every time ?
Actually, one thing that did just occur is to specify the $(Platform)\$(Config) part of the path in the project settings themselves, rather than in the DCU variable. If it works (I can’t try it yet – XE2 is still installing) this would make setting this variable on every project a little more irksome, but eat least once done everything else would work as expected. If it works. I shall update this post one way or the other when I have the answer.
Update: Fortunately this does in fact work.
But seriously. This is what we have to deal with ?
With a “PROFESSIONAL” development tool ?
However professional the users are expected to be, it appears that back at Embarcadero it’s Amateur Hour.
will be fixed in XE6. probably.
Don’t give them ideas. They might decide that for Professional users they’ll put it in a “Usable IDE Add-On” ? 😀
> c:\dev\dcu\xe2\%platform%\%config%
This happens rarely, but when it happens – you only have to restart IDE
Worse – there is no clear to see indicator, that this mess started happening, you can only grasp it by intuition.
XE2 u4hf1
Seems to happen consistently for me, although I haven’t yet done exhaustive testing with U4HF1 (sounds like a strain of bird flu!).
> one thing that did just occur is to specify the $(Platform)\$(Config) part of the path in the project settings themselves
You really can do, And using OptSets, you can do it uniformly for different modules of the project and separate debug and release builds.
However, personally, i experience another misfeature: while optset-based redirections generally works (ProjectPath}\Win32\Debug subfolder is always recreated. It remains empty, yes. But it GETS RECREATED :-E~~~
I’ve never worked at a place that produced more than one target build of an app, although I can see how this would be an issue for component and library vendors. My guess is stuff like this falls through the cracks because at that point you’d probably be using something like FinalBuilder to manage your builds rather than the stuff built into the IDE.
Frankly, this stuff seems to change in the IDE every release or two, and following it can be dizzying. I’d much rather rely on a tool like FinalBuilder that lets me specify a single coherent set of rules that produce the correct results for all platforms than have to deal with the myriad of differences between successive IDE releases and changes.
BTW, you might consider publishing a smallish eBook on Kindle that explains how you set up your various VMs and host environment to do what you do, along with things you’ve tried that you later changed your mind and why you did that. There’s virtually nothing documented on this anywhere, and I’m sure lots of folks would happily pay $10-$20 for something that saves them hours upon hours of fiddling with crap that you’ve already figured out. That’s what books are for, after all. 🙂
That eBook idea is a good one, thanks for the suggestion.
As far as using FinalBuilder or it’s like, yes, I am considering those options. I introduced FinalBuilder to my employer and we are using it very successfully, but just between you, me and the gatepost, I find it a bit cumbersome. Not to mention expensive for non-commercial purposes. If there were a free edition I would probably just use it, but as it is I am looking at other options.
I’m just starting to look into “Train” from RemObjects. It’s free and open source. https://github.com/remobjects/train
Apparently, the RO team created it to work around some inflexibility they had with FinalBuilder. Unfortunately, I’m not far enough into it to comment on its merits, but if it’s good enough for RO, I’m guessing it may be satisfactory for many.
How had I not heard of Train before now ?
Thanks for the tip – definitely worth looking into!
In combination with the use of Continua CI, which is free for non-concurrent deployment you end up with a very nice web based project builder.
>But seriously. This is what we have to deal with ?
>
>With a “PROFESSIONAL” development tool ?
>
>However professional the users are expected to be, it appears that back
>at Embarcadero it’s Amateur Hour.
Wow, you don’t know how many times I’ve started to write EMBT forum posts that used those exact words, “Professional” and “amateur hour”, then thought better lest the outrage flow and I be banned on the spot. One user has already requested I be banned because “you just want to turn Delphi into C# or Python”. (Of course, EMBT would make me CEO if I really could do that!)
When comparing Delphi today to free, open source offerings, it often does seem that Delphi feels like “amateur hour” and the free offering the “professional” tool. We have third parties providing profiling support because Borland/Inprise/Codegear/Embarcadero never did. We have third parties providing the logging support. We have third parties providing unit testing support. We have third parties providing documentation generation support. Embarcadero may be bundling stripped-down 3rd party versions of these things today (doubling the price of Pro if you actually buy the full versions from the bundled vendors), but these are not things you want to leave up to the fate of third parties. Already we have DUnit development in limbo and multiple forks taking place right now. I don’t think of profiling, logging, unit testing or document generation being optional for professional work. The open source tool I’m using for a project right now develops all of those features as part of the reference implementation of the language and includes them “in the box”. This makes Delphi feel like amateur hour in comparison (especially for the years I used Delphi when these weren’t included and in the early years didn’t even exist as 3rd party offerings yet).
The method EMBT uses to let us know of new features/changes in the product. “SURPRISE!!!” We don’t even know what day it’s going to be released! (And this year, neither did their own marketing team.) We have little idea what’s coming in the new release or even when it will be available until it hits or NDAS are selectively lifted on EMBT mouthpieces a few days prior.
For the tool I’m using now, I have a list of release dates of each alpha, beta, and release candidate for the next version, as well as the specific day in Feb. 2014 the final version will be released. The documentation for the next version has been available on their website since before the first alpha was released and it gets updated as new features are added to the product. What amount to white papers are produced for every significant change in the syntax or standard library addition and these are also added to the website so one can not only read the details of how a forthcoming feature will be implemented, but a detailed discussion on why it was added, why it works the way it does, answers to objections, etc. This language is adding enums and I already know exactly how they work months before release – in fact, they recently produced a library backporting enums to several previous versions so one can begin working with them today before the new version is released! (David I would shave his beard before EMBT would ever dream of backporting a feature).
Developer mailing lists are open and available. Any user may submit a (detailed, researched, well-written) proposal and have it discussed and debated by core devs and a decision ultimately made and presented on whether it will be included. One does not have to offer sacrifices (or, commonly, take out torches and pitchforks) like we do to get an EMBT employee to descend from Delphi Mountain and speak with the mere mortals.
All this and so much more does indeed make Delphi feel like amateur hour to me today. I think it’s something like Stockholm Syndrome where we started to identify with our captors and end up paying for the privilege of getting worse service and more bugs and needing to deal with so many issues ourselves. It’s amazing when one finally tries a non-EMBT language and realizes how much higher the standards are elsewhere and what we’ve been missing.
Sorry to write so much, but this professional vs. amateur hour theme has been running through my head for several weeks now.
Why not use package manager for Delphi?
It takes care on vendor libraries paths, platforms/configurations etc
If you mean Owlyci, I looked it up but the documentation is not very clear. Very detailed, but not clear as to what it is useful for. As far as I can tell it looks like something I might use to make life easier for users of any code I might publish but I am not at all clear as to how it makes the job of managing the development and testing environments for the source projects themselves.
If there are some clearer docs showing how it can/should be used in that context I’d be interested in taking a further look.