-
Notifications
You must be signed in to change notification settings - Fork 22
Home
I've set up a sub-Reddit section for discussion purposes, since GitHub doesn't have really much in the way of discussion fora functionality. It may still be empty since it was just created.
CIDLib is easy to build. But it is a full featured system and so there's a good bit of prep work needed to get the environment set up.
The following need to be installed.
As a rule, probably generally a good one, don't let any of these guys set actual Windows environment variables, other than to add themselves to the PATH at most. We want to control the environment ourself. I don't think any of them actually do try to set up anything other than the path these days.
- Windows 7 or above
- Visual Studio 2019.
- Windows Platform SDK 10
- The Microsoft Speech Platform SDK 11. This is still, AFAIK, not part of the platform SDK that gets installed with VS.
- The Windows Media Format SDK (still not in the regular platform SDK, right?)
- The Windows Media Player SDK (still not in the regular platform SDK, right?)
- The Quick Time SDK (only really used in CQC so far, the iTunes COM interfaces are in the .\Depends\SDKs directory, this is the actual SDK/engine.)
- LibVLC. Here again, currently really only used in CQC so far, and the headers/libraries are in the .\Depends\SDKs directory, this is the actual VLC player and DLLs.
- Scintilla but everything needed is in the .\Depends\SDKs directory, so nothing to do here.
You will need to set up a few things in the environment. Or, if you don't want to do that, then below where we invoke the environment command file, put your own file first, set these up, then call the the actual one. The command file opens a command window which will inherit the variables either from the environment or from your own command file being run first.
CID_DEVTREE - This is the top of the development tree. Because there may be others that are based on CIDLib and part of the same build environment, you should do some sort of setup like this:
- C:\Whatever\MyWork\CQSL
- C:\Whatever\MyWork\CQSL\CID_Dev
Point this variable at the CQSL directory, and put the CIDLib code into the CID_Dev directory. The environmental setup file will add the CID_Dev sub-directory. Any other related repos will do the same for their own sub-directories, such as CQC, which you would put in:
- C:\Whatever\MyWork\CQSL\CQC_Dev
and so forth. The CQC setup command file will add that CQC_Dev directory. Because the setup files just add their own specific repository directory to usually global CID_DEVTREE value, they generally need to be sibling directories.
The rest are to let the build environment setup files get the INCLUDE, LIB, and other paths set. These are listed below, with examples from my own system, which is currently on Visual Studio 16.8.4. They should be fairly self-explanatory. The two VER ones are the specific versions of the platform SDK and Visual Studio tools you have installed, since those versions are in the paths to the various bits and pieces.
- CID_PLATSDKVER=10.0.18362.0
- CID_QTSDK=C:\Program Files (x86)\QuickTime SDK
- CID_SPEECHPLATDIR=C:\Program Files (x86)\Microsoft SDKs\Speech\v11.0
- CID_VSTOOLSVER=14.28.29333
- CID_VSTUDIOPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
- CID_WMFSDKDIR=C:\Program Files (x86)\Microsoft SDKs\WMFSDK\WMFSDK9
- CID_WMPSDKDIR=C:\Program Files (x86)\Microsoft SDKs\WMPSDK\WMPSDK10
You may need to use Enterprise instead of Community in your CID_VSSTUDIOPATH, depending on what version you have.
On Linux various standard or common libraries need to be installed. I will be honest I can't really enumerate them very well yet because I am not a big Linux guy and I don't know for sure what all ultimately has ended up being really required. I'll have to dig into this more. The build system is working on Linux, the set up is just not as well worked out and refined yet. CIDLib is a 32 bit system, so the 32 bit versions of the libraries will be needed.
Once those are in place you should add a general command line shortcut to your desktop somewhere. It will invoke the setup file which will set up everything you need into a command line windows.
You should set up the Target: value (the command line to invoke) to be something like:
%SystemRoot%\System32\Cmd.exe /k %CID_DEVTREE%\CID_Dev\Source\Cmd\Win32\SetCIDEnv.Cmd Dev WIN32_WIN7 D: \Whatever\MyWork\CQSL\CID_Dev
This will invoke Cmd.Exe to run a command window. /k will make it stay open after the command file is run. It uses CID_DEVTREE above to find and invoke the CIDLib environment setup file.
The above command passes the following values to the setup file:
- Build Mode - This will be Dev or Prod for develop or production builds.
- Target Platform - Currently the only one is Windows 7 in Win32 mode, which is WIN32_WIN7
- Target Drive - The drive (with colon) that the CIDLib code is on. It's sort of redundant but it's annoying to parse stuff out in the Windows batch language, so it's easier to just provide it than to try to get it out of a passed path
- CID_Dev directory path - This is the path (minus drive and colon) to your CID_Dev directory. You might think you could use CID_DEVTREE here as well, but it includes the drive, so that won't work. That's something that would be worth fixing at some point.
That's it for the environmental setup. You can set up two of these guys, and give one the name CIDLib Debug and one CIDLib Production or whatever, and set the first parameter to Dev for one and Prod for the the other.
The Linux platform works very similarly. It will set up basically the same environment variables (since it uses the same CIDBuild build tool that looks for them.) You can set up a short cut that invokes a command file just like on Windows and it will set everything up for you. This will be documented here at some point as I get it more refined.
To run the environment setup, invoke your short cut to open the command prompt. On Windows right click and run as Admin. It's possible everything will work without running as admin, but I think some of the tools might require it. If you are paranoid, just look through the SetCIDEnv.Cmd file that gets invoked. It's just environment setup stuff.
That will open a command line prompt. You should be able to do something like:
CCD Root
and it should go to your CID_Dev directory. If so, you are roughly correct. Manually invoke the various development tools, such as cl, link, g++ and so forth to make sure that the development system environment is set up correctly.
The first thing you need to do is build the build tool. This is part of the bootstrapping process. This one is built via a simple make file. So type "CCD cidbuild" which should take you to the CIDBuild directory. Then run this command:
Win32\Cmp (or Linux\Cmp on Linux)
That should build the build tool. If that succeeds, then probably the basic development environment is good. If there are errors, then post the error output for comment. You should be able to run:
CIDBuild
And get the usage output from the build tool if it got built correctly.
Once you have the build tool built, then you need to do a bootstrap build. There are some bootstrapping issues invoked when you are building CIDLib itself from an empty output directory. Because CIDLib uses its IDL compiler in a lot of places, that has to get built first, then the IDL compiler gets invoked for the whole code tree to generate all of the IDL output files, then a full build needs to be done.
You can do that with this command:
CIDBuild /action=bootstrap
You should see it building CIDKernel, CIDLib, CIDXML and a few others that the IDL compiler needs. Then it will invoke the IDL compiler, then it will start building everything else.
If that completes successfully, then you have a working CIDLib build. Again, if not, post the errors and we can explore what's wrong. Once the bootstrap build is done, you don't have to invoke it again unless you trash the output directory and need to build from scratch again, or we move to a new version (each version has its own output sub-directory so that multiples can co-exist.)
On Linux we aren't that far along. For now we are still working on CIDKernel so you need to just build it directly, or you can build the low level test that is currently being used to bang out the CIDKernel implementation:
CIDBuild /target=CIDKernel (or CIDBuild /target=TestKernel to build the test)
Everything is pushed to the output directory. Under there you should see a directory that is the current working version. Under there will be DevResult and ProdResult directories (at least for the Dev/Prod modes you have built for) that have all of the output.
For each facility (DLL/Exe) there will be a [name].Out directory where the object files and other bits go. The executable and library files and related compiler housekeeping files are in the DevResult/ProdResult directories. There will be Includes and PrivIncludes directories where the headers are copied. The debugger will see these headers.
The output directories are in the path so you can run any of the built programs of course.
The CIDBuild tool does header dependency analysis. All system headers use <> brackets and all CIDLib (and your) headers should use "" quotes. CIDBuild knows that the latter are ones it cares about. It will generate a [name].Depend file in the [name].Out directory for each facility.
If you change headers you need to update the dependency file. You can do that like this:
CIDBuild /action=makedeps
If you don't give a target project, it does them all. If you want to do a specific facility project do:
CIDBuild /action=makedeps /Target=CIDLib
or whatever the target project is. If you know you don't need to recurse into other projects it depends on, use the /NR flag:
CIDBuild /action=makedeps /Target=CIDLib /NR
If you don't give an action then a build is assumed, so:
CIDBuild /Target=CIDIDL
will build the CIIDDL project and any underlying projects. If you know you don't need to recurse (you only changed stuff at this level) you can use /NR.
CIDBuild /Target=CIDIDL /NR
If none of the underlying stuff had changed, then they wouldn't actually rebuild anyway, but you avoid the need for the compiler to have to figure that out himself. And of course, if you are working on a library facility, and changed any publicly visible files, you need to build anything that uses it. So just do:
'CIDBuild'
To rebuild anything that needs rebuilding based on dependencies. It would be nice to have a command to just rebuild things that depend on a specific library facility. I'll put that on the list.
I'll leave it there for this document. This is enough to sort of bootstrap the process. The rest of the docs will be in the actual repo and built to HTML using a tool you'll build above (that is not done yet, just saying that is how it will work.) So I want to keep this part as basic as is reasonable.