In last nights tech tip:
http://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/bear_blog/archive/2013/12/11/tech-tip-easy-method-of-locking-variables.aspx
I mentioned that the lock cfg files will only effectively work if we bypass the need for pcf files. The reality for many of us is that the fixed approach Bentley takes to cfg load order just isn't adequate. To be honest, the beauty of Bentley products is that what is delivered is merely a template. What you do with that template is boundless and only limited by your knowledge and creativity when it comes to builds. Over the last 20 years I've lost count of the number of different ways companies have come up with to make life as hard as they can for themselves, but I'm yet to come across any system that you can't adapt cfg files and variables to work with.
So, if not a pcf, then what?
Well, all we need to do is use the site cfg files to work for us. The important cfg file in this is 30_inclusions. I've done a bit with this file before when looking to include other applications in our builds:
http://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/bear_blog/archive/2012/10/09/the-build-part-4-all-aboard-the-cfg-ride-including-other-apps.aspx
The project variables, we'll call it that for this exercise, is set from the drop down in our hta file. All we do now is use a '%if exists' statement to call up our project cfg file if one exists. This is important as we only need to use the project cfg file is we wish to override any part of our main build. In my cfg file I use:
%if exists ($(STD_PROJECT)$(PROJECT).cfg)%include $(STD_PROJECT)$(Project).cfg_USTN_PROJECTDESCR = $(PROJECT)%endif
It's as simple as that really. This file can now be used for any changes or to simply include other cfg files that could be part of a project or client build. For me, I mainly use the $(Project).cfg file to access 'client' builds. I've found, over the year,s that the client name on it's own is not always a good trigger for builds. In many situations, you may keeps projects under a client direcotry, but each project could use any number of different client or company builds. It's easy enough to trigger the use of these builds from the $(Project).cfg. One I use is:
Client = _RioTinto%include $(ClientDir)$(Client).cfg
Pretty straight forward really and an example of just how easy it is to adapt builds to just about any situations.
Remember, all path variables you use are set in 10_folders.cfg. Make sure these are set correctly or you will have issues.
More soon and enjoy the run up to Christmas 2013.