Rebranding the DCL to the CML, and other changes

With the move back to the ClarionMag brand, I realized I'd better rebrand the site's signature library, until now known as the DevRoadmaps Clarion Library (DCL), as the ClarionMag Library (CML). 

To begin with I simply made a copy of the entire DCL development directory tree. I then went in to the libsrc directory and issued a 

ren DCL_* CML_*

command, which worked only because I maintained the same number of characters at the start of the name. 

I then loaded up all of the text files in that directory with Notepad++ and did a similar search and replace across all files (I could have used Clarion, but I like NPP for bulk operations). There were 1751 occurrences, so definitely this isn't something I'd want to do by hand. 

I went through the same process with the templates. I was a bit worried about the template changes, because I have a lot of test apps that use the DCL templates and classes, and if I renamed the templates (not just the tem plate files) I'd have to recreate all of the test apps from TXAs. But it turns out I didn't use the DCL_ prefix in template names, so all I really need to do is unregister the old templates and register the new ones. 

And of course I had to rename all of the unit test apps. I always do this by opening the app and doing a Save As to another name. I have a vague primal memory of once doing this with a DOS rename and having everything go south because none of the internal names were changed, e.g. for the target. Thinking it might be safe to do so now, I experimented. And no, the target name is still not changed if you do a DOS rename, and my paranoia is probably justified. 

But it will take some time to go through all of the unit test apps, so for now I've left them out of the repository. They'l be back soon. 

Renaming the library DLL and LIB to CMgLib

When I first did the conversion I renamed the DevRoadmapsClarion project to ClarionMagLibrary. But that means that to ship product using the library you need to include a file called ClarionMagLibrary.dll with your product. Although I'd like all Clarion devs to know about and use the ClarionMag library, I'm not trying to advertise to everyone's clients. So I decided to make the actual DLL/LIB name a bit more cryptic. I thought about "CMLib" but a Google search for CMLib.DLL resulted in over 15,000 hits. 

A Google search for CMagLib.DLL, however, yielded just two hits, only one of which was an actual match. So the new project name for the library is CMagLib. 

Renaming a hand coded project isn't all that difficult. All the file names need to be reloaded, and then you need to load up the project and solution files and do a search and replace. In my case I also needed to do a search and replace for the files used by the CreateExportFile utility, which automatically generates the EXP file for all the classes exported by the library. 

Compiling for multiple Clarion versions

Although the need for version-specific recompiles declined with Clarion 8, there are times when you need an updated or older version of a library. 

For a long time now I've kept multiple installs of Clarion on my machine. I also keep two copies of each install - a clean install, and one configured the way I usually use Clarion. As well, I typically only use the latest version of any given release, so my directory tree looks like this:

The real question is how do I create builds of the library for each release, or at least each release that needs an updated build? 

One factor strongly in favor of automating the process is the library itself is a hand coded project, so I don't need to worry about keeping multiple versions of APPs around. The .cwproj files can be compiled in any release of Clarion from 8 (and probably 7, although I don't currently have it installed) onwards. 

After some experimenting, I settled on the following batch files. 

call CompileForClarionVersion versions\8.0.9661
call CompileForClarionVersion versions\8.1.9759
call CompileForClarionVersion versions\9.0.10294
call CompileForClarionVersion versions\9.1.10741
call CompileForClarionVersion 9.1 baseline

CompileCMagLibrary.cmd uses a naming convention that follows my ClarionInstalls directory structure, and passes in the version folder name. 

CompieForClarionVersion.cmd is a bit more complicated:

@echo off
if not exist f:\ClarionInstalls\%1\bin (
	echo.
	echo The Clarion release directory f:\ClarionInstalls\%1\bin could not be found
	echo.
	exit /b 1
)
echo.
echo Building ClarionMagLibrary for release %1
echo.
echo Compiling CMagLib.cwproj
echo.
call CompileCWProj.cmd  CMagLib.cwproj f:\ClarionInstalls\%1\bin
echo Compiling CreateExportFile.cwproj
echo.
call CompileCWProj.cmd  CreateExportfile.cwproj f:\ClarionInstalls\%1\bin
if "%2"=="baseline" (
	set BINFOLDER=..\bin
	set LIBFOLDER=..\lib
) else (
	set BINFOLDER=..\bin\%1
	set LIBFOLDER=..\lib\%1
)
echo.
echo BINFOLDER %BINFOLDER%
echo LIBFOLDER %LIBFOLDER%
echo.
echo Copying binary files...
echo.
if not exist %BINFOLDER% mkdir %BINFOLDER%
copy CMagLib.dll %BINFOLDER% /y
copy CreateExportFile.exe %BINFOLDER% /y
if not exist %LIBFOLDER% mkdir %LIBFOLDER%
xcopy ..\build\obj\debug\CMagLib.lib %LIBFOLDER% /D /Y
xcopy ..\build\obj\release\CMagLib.lib %LIBFOLDER% /D /Y

There are a few little tricks here. I'm setting a destination folder for the bin and lib files that matches the version used to compile the library, and I'm creating the folder if it doesn't exist. Also I'm using xcopy to bring the latest version of the library over, which may be the debug version or the release version. I don't want to copy an earlier debug version over a later release version or vice versa. 

I still want a final compile that puts the latest version of the library in the default bin and lib directories. The "baseline" flag takes care of that. 

Finally, there's CompileCWProj.cmd:

@echo off
if "%1"=="" (
	echo You must specify a project as the first parameter
	exit /b 1
)
if "%2"=="" (
	echo You must specify a Clarion bin directory as the second parameter
	exit /b 1
)
if not exist %1 (
	echo Cannot find the project: %1
	exit /b 1
)
if not exist %2 (
	echo Cannot find the Clarion bin directory: %2
	exit /b 1
)
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\msbuild" %1 /p:vid=min;line_numbers=True /property:ClarionBinPath="%2"
if %errorlevel% neq 0 goto error
exit /b 0

:error
@echo CompileClarionProject.cmd returning error 1 on errorlevel %errorlevel%
exit /b 1

The meat is near the end, where the command line compile is invoked via MSBuild. Note the /p:vid=min;line_numbers=True option which tells the compiler to include the minimum amount of debugging info to allow for easy tracking down of GPFs when using the debug version of CLARun.dll. Given this option I don't really need the xcopy trick above, but if at some point I switch to a non-debug compile I'll have saved myself some grief. 

Here's the ClarionMagLibrary directory tree with the bin and lib nodes expanded:

If you need a different version of the library, please post a comment below and I'll add it to the build process. 

I'll be posting more on the code available inside the CML soon - stay tuned.