Double clicking on a workspace file to generate a solution
It it possible to allow for double clicking on a ceda workspace file (extension xcws) and have the MSVS project and solution files generated automatically.
Consider the following directory structure:
C:
└── developer
├── _root_
│ ├── Ceda
│ │ ├── _BUILD
│ │ │ └── XcppConfig
│ │ │ ├── base.xcpp
│ │ │ ├── compiler.xcpp
│ │ │ ├── msys2.xcpp
│ │ │ └── selectcompiler.xcpp
│ │ └── Core
│ │ ├── cxLss
│ │ ├── cxMessage
│ │ ├── cxObject
│ │ ├── cxOperation
│ │ ├── cxPersistStore
│ │ ├── cxPython
│ │ ├── cxRmi
| | │ └── src
| | │ └── cxRmi.xcpj
│ │ ├── cxThread
│ │ ├── cxUtils
│ │ ├── cxWorkingSetIpc
│ │ └── wsRmi.xcws <── a ceda workspace file
│ └── .xcwsroot
├── XcppConfig
│ ├── machine_local.xcpp
│ └── selectcompiler.xcpp
└── build_dir.bat
.xcwsroot file
The folder _root_ contains a zero length file named .xcwsroot. This is a marker indicating that _root_ represents a root of a physical tree, which is available for defining a virtual tree.
machine_local.xcpp
c:/developer/XcppConfig/machine_local.xcpp might have the following content:
@importpath "$(PATH_TO_ROOT)/Ceda/_BUILD/XcppConfig"
@def+ bool UseVisualLeakDetector = false
@import "base.xcpp"
selectcompiler.xcpp
c:/developer/XcppConfig/selectcompiler.xcpp might have the following content:
// Possible values : Winx86, Winx64, Linuxx86, Linuxx64, MacOSXx86, MacOSXx64
@$DEV_PLATFORM = "Winx64"
// Possible values : vc6, vc8, vc9, vc10, vc11, vc12, vc14, gcc, winegcc, clang
@$COMPILER = "vc14"
// Only applicable to vc8,vc9,vc10,vc11,vc12,vc14.
@def+ bool IsExpressCompilerVersion = true
build_dir.bat
Let c:/developer/build_dir.bat set an environment variable named BUILD_DIR to the relative path (i.e. from c:/developer) to the build folder:
@set BUILD_DIR=build_rmi\build
Content of CMD window when double click on workspace file
If the user double clicks on a workspace file a command window pops up with information about the generation of a build artefacts folder containing a number of files including MSVS project and solution files.
For example this output is written to the console window when double clicking on the ceda workspace file with logical path Ceda/wsRmi.xcws.
Generated build artefacts structure
This has generated the build artefacts folder c:/developer/build_rmi, with the following tree structure:
C:
└── developer
└── build_rmi
├── build
│ ├── Win32
│ │ ├── Debug
│ │ │ ├── cxMessage
│ │ │ ├── cxObject
│ │ │ ├── cxRmi
│ │ │ ├── cxThread
│ │ │ ├── cxUtils
│ │ │ └── cxRmi
│ │ └── Release
│ │ ├── cxMessage
│ │ ├── cxObject
│ │ ├── cxRmi
│ │ ├── cxThread
│ │ ├── cxUtils
│ │ └── cxRmi
│ ├── x64
│ │ ├── Debug
│ │ │ ├── cxUtils
│ │ │ ├── cxMessage
│ │ │ ├── cxThread
│ │ │ ├── cxObject
│ │ │ └── cxRmi
│ │ └── Release
│ │ ├── cxUtils
│ │ ├── cxMessage
│ │ ├── cxThread
│ │ ├── cxObject
│ │ └── cxRmi
│ ├── clean.bat
│ ├── gen_wsRmi.bat
│ ├── build_local.xcpp
│ ├── wsRmi.translate.xcpp
│ ├── wsRmi.xcpp
│ ├── cxUtils.vcxproj
│ ├── cxMessage.vcxproj
│ ├── cxThread.vcxproj
│ ├── cxObject.vcxproj
│ ├── cxRmi.vcxproj
│ ├── build_cxUtils.vcxproj
│ ├── build_cxMessage.vcxproj
│ ├── build_cxThread.vcxproj
│ ├── build_cxObject.vcxproj
│ ├── build_cxRmi.vcxproj
│ ├── wsRmi.sln
│ └── build_wsRmi.sln
├── export
│ ├── Ceda
| | └── Core
| | ├── cxUtils
| | │ └── src
| | │ └── cxUtils.xcpj
| | ├── cxMessage
| | │ └── src
| | │ └── cxMessage.xcpj
| | ├── cxThread
| | │ └── src
| | │ └── cxThread.xcpj
| | ├── cxObject
| | │ └── src
| | │ └── cxObject.xcpj
| | ├── cxRmi
| | │ └── src
| | │ └── cxRmi.xcpj
| | └── wsRmi.xcws
│ └── .xcwsroot
├── include
└── lib
├── Win32
│ ├── Debug
│ └── Release
└── x64
├── Debug
└── Release
build_local.xcpp
@importpath "$(PATH_TO_ROOT)/../XcppConfig"
@import "machine_local.xcpp"
wsRmi.xcpp
@$PATH_TO_ROOT = (@relativepath(r"C:\developer\_root_",r"C:\developer\build_rmi\build"))
@import "build_local.xcpp"
pathRootToXcws = "Ceda/wsRmi.xcws"
wsRmi.translate.xcpp
@$PATH_TO_ROOT = (@relativepath(r"C:\developer\_root_",r"C:\developer\build_rmi\build"))
@import "build_local.xcpp"
translateOnly = true
rebuildAll = true
pathRootToXcws = "Ceda/wsRmi.xcws"
gen_wsRmi.bat
@%CEDA_LOCAL_XCPP_DIR%\xcpp wsRmi.xcpp mode=gen
@if %1x==x pause
clean.bat
rmdir /S /Q ..\lib
rmdir /S /Q ..\include
rmdir /S /Q ..\export
rmdir /S /Q xcppsource
rmdir /S /Q Linuxx86
rmdir /S /Q Linuxx64
rmdir /S /Q MacOSXx86
rmdir /S /Q MacOSXx64
rmdir /S /Q Win32
rmdir /S /Q x64
rmdir /S /Q Backup
rmdir /S /Q ipch
del make*.*
del *.vcproj
del *.vcxproj
del *.vcxproj.user
del *.vcxproj.filters
del *.sln
del *.geany
del *.cbp
del *.layout
del *.depend
del *.workspace
del *.make
del *.projects
del *.xcppdep
del *.user
del /A:H *.suo
del *.sdf
del *.ncb
del *.guids
Launching MSVS
To launch the MSVS IDE simply double click on the generated solution file (c:/developer/build_rmi/build/wsRmi.sln).
Building the solution
An external tool is used to build the solution. Typically Ctrl+4 is pressed to run this external tool.
Pressing Ctrl+4 causes the solution to be build, information is displayed in the Output pane
The text written to the Output pane can be seen here.
Intermediate files written to the build folder
Intermediate files such as obj, pch and pdb files are written under the build folder. For example:
C:
└── developer
└── build_rmi
└── build
└── Win32
└── Debug
├── cxMessage
├── cxObject
├── cxRmi
├── cxThread
├── cxUtils
└── cxRmi
├── cxRmi.obj
├── cxRmi.pch
├── ResponseQueue.obj
├── RmiCallee.obj
├── RmiCaller.obj
├── Skeleton.obj
├── StdAfx.obj
├── Stub.obj
├── ThreadBlocker.obj
└── vc140.pdb
Straight C++ files which have been derived ("translated") from corresponding Xc++ files are written under the xcppsource folder under the build folder. These are made read-only because they are generated files.
Projects which are already straight C++ (such as cxUtils and cxMessage) don't appear under the xcppsource folder.
For example:
C:
└── developer
└── build_rmi
└── build
└── xcppsource
└── Win32
└── Debug
└── Ceda
└── Core
├── cxObject
│ ├── src
...
└── cxRmi
├── src
│ ├── cxRmi.cpp
│ ├── ResponseQueue.cpp
...
│ ├── ThreadBlocker.cpp
│ └── ThreadBlocker.h
├── cxRmi.h
├── Rmi.h
├── RmiConnection.h
├── Skeleton.h
└── Stub.h
Files written to the export folder
The export folder is written with:
- A zero length file named .xcwsroot at the root folder to mark the folder as a physical tree root available to be used to define a virtual tree
- The original ceda workspace file with the original logical path
- Derived project files for each project with the original logical path, but only specifying the public header files in the project
- The public header files for each project, for both straight C++ projects such as cxUtils and Xc++ projects such as cxRmi. In the latter case the original untranslated header files are written under the export folder - i.e. they are expressed in the Xc++ language, not straight C++
C:
└── developer
└── build_rmi
└── export
├── .xcwsroot
└── Ceda
└── Core
├── cxUtils
│ ├── src
│ │ └── cxUtils.xcpj
| ├── Archive.h
| ├── ArchiveDeque.h
...
| └── xvector.h
├── cxThread
│ ├── src
...
├── cxMessage
│ ├── src
...
├── cxObject
│ ├── src
...
├── cxRmi
│ ├── src
│ │ └── cxRmi.xcpj
│ ├── cxRmi.h
│ ├── Rmi.h
│ ├── RmiConnection.h
│ ├── Skeleton.h
│ └── Stub.h
└── wsRmi.xcws