Configure MinGW in Visual Studio Code

Just make some time for me to try out the tool - Visual Studio Code (VSC). It is a new toy from Microsoft. This writing was mainly for Windows platform targeted on MinGW compiler because I found out the setup in Windows is far more "complicated" than Linux. I think this is very rare for people living in the Windows world, but using MinGW as the primary compiler. Basically, there 3 configurations needed for my use case: c_cpp_properties.json, tasks.json, and launch.json.

c_cpp_properties.json

Linux was working fine without this file, but I am not sure why this file is needed for Windows. This file basically tells the tool how those declarations/definitions are resolved in the source file. Since I’m working on Windows, I will only focus on Win32 section. In my case, I need to tell the editor that I got extra MinGW header files located in other path. These paths are added into includePath. compilerPath tell the VSC where the compiler is located, unless the path has been added to the environment variable, then this field is optional. The default intelliSenseMode value was set to msvc-x64. It has to be changed to clang-x64 because this will throw a bunch of error on the std namespace declaration. The code snippet below shows the affected section:

{
    "configurations": [
        {
            "name": "Win32",
            "compilerPath": "C:/MinGW/bin/g++.exe",
            "includePath": [
                "C:/MinGW/include",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++/tr1",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++/mingw32",
                "C:/tool/gsoap-2.8.55/gsoap",
                "${workspaceFolder}"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "${workspaceFolder}"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "cStandard": "c11",
            "cppStandard": "c++17"
        }
    ],
   … 
   …
}

tasks.json 

This file is to tell how the source is going to build. Before the file is created, I’m using the following command to build the source.

g++ -o main.exe main.cpp soapC.cpp soapServiceProxy.cpp c:/tool/gsoap-2.8.55/gsoap/stdsoap2.cpp 
-I. -Ic:/tool/gsoap-2.8.55/gsoap 
-Lc:/MinGW/lib -Lc:/MinGW/lib/gcc/mingw32/6.3.0 
-lws2_32 
-std=c++11

In the configuration file, the value of args is reflecting the command. But sometimes when the error occurred, I’ll go back to the command line to do a few rounds of testing to ensure it is working before come to the final configuration. Sometimes the build may not reflect on the latest changes, just close and reopen the VSC will resolve the issue.

"tasks": [
        {
            "label": "build testlab",
            "type": "shell",
            "command": "g++",
            "args": [
                "-g", 
                "-o", "main.exe",
                "main.cpp soapC.cpp soapServiceProxy.cpp c:/tool/gsoap-2.8.55/gsoap/stdsoap2.cpp",
                "-Ic:/tool/gsoap-2.8.55/gsoap",
                "-I.",
                "-Lc:/MinGW/lib",
                "-Lc:/MinGW/lib/gcc/mingw32/6.3.0",
                "-lws2_32",
                "-std=c++11"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]

launch.json 

This file is to tell whether the program will start in debug mode or not. Basically, this file is ready to use when it was first generated, I just update the program field point to my program name, which is main.exe.

"configurations": [
    {
        "name": "(gdb) Launch",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceFolder}/main.exe",
        "args": [],
        "stopAtEntry": true,
        "cwd": "${workspaceFolder}",
        "environment": [],
        "externalConsole": true,
        "MIMode": "gdb",
        "miDebuggerPath": "C:/MinGW/bin/gdb.exe",
        "setupCommands": [
            {
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
            }
        ]
    }
]

Unit test code strategy on private method

During the initial development, the code was driven by the TDD concept. Thus, I have the following code published to the world temporarily. The 2 methods are the primary methods of this program; neither one of them missing will not work.

public:
    FileNode* constructParentPath(boost::filesystem::path inputPath);
    void constructChildPath(FileNode *currentRootNode);

    ...
    ...

This design was to make sure that I have enough test coverage for each method. After unit testing have been done, I have a plan to change the visibility of that 2 primary methods to private, and replace them with a more meaningful method. The new design would look like below:

public:
    FileNode* constructAbstractPath(boost::filesystem::path inputPath);


protected:
    FileNode* constructParentPath(boost::filesystem::path inputPath);
    void constructChildPath(FileNode *currentRootNode);


FileNode* FileBot::constructAbstractPath(boost::filesystem::path inputPath)
{
    constructParentPath(inputPath);
    constructChildPath(root);

    return root;
}

Ahhaa~ Feeling so nice with this method now. But the flip site of this change will spoil my existing unit test code. Thus, I think of a new solution that wouldn't make such a huge change while adapting the new design. I made a new class that mimics the existing method call as shown in below:

class FileBotUnderTest : public FileBot
{
public:
    FileBotUnderTest();

    FileNode* constructParentPath(boost::filesystem::path inputPath) {
        return FileBot::constructParentPath(inputPath);
    }

    void constructChildPath(FileNode *currentRootNode) {
        return FileBot::constructChildPath(currentRootNode);
    }
};

Changes in unit test code are very minimal, instead of interacting with FileBot, I'll just interact with FileBotUnderTest. Below are the work done for these changes:

BOOST_AUTO_TEST_CASE(TL_6, *boost::unit_test::precondition(skipTest(true)))
{
    BOOST_TEST_MESSAGE("TC6 : load 3 level parent path");
    string path = "";
    FileBotUnderTest fb;

#if defined(WIN32)
    BOOST_TEST_MESSAGE("Test path: D:\\workspaceqt\\ui1");
    path = "D:/workspaceqt/ui1";
#else
    BOOST_TEST_MESSAGE("Test path: /home/kokhoe/workspaceqt");
    path = "/home/kokhoe";
#endif

    if( fb.constructParentPath(path) != nullptr )
       path = fb.getParentPathAddress();

#if defined(WIN32)
    BOOST_TEST(path == "D:\\workspaceqt\\ui1\\");
    fb.clearMemory();
#else
    BOOST_TEST(path == "/home/kokhoe/");
#endif
}