Combine libcommon headers with source

[ejaquay]

Currently libcommon headers (.h files) are held seperately from other libcommon sources ( .cpp file). This is not consistant with the way the rest of VCC sources are organized. I think the lib common tree should look like this with headers combined with other sources:

 |
 |--libcommon
 |  |-- libcommon.vcxproj
    |-- libcommon.vcxproj.filters
    |-- resource
    |   |-- libcommon.rc
    |   `-- resource.h
    `-- vcc
        |-- main.cpp
        |-- cartridges
        |   |-- capi_adapter_cartridge.cpp
        |   |-- capi_adapter_cartridge.h
        |   |-- empty_cartridge.cpp
        |   |-- empty_cartridge.h
        |   |-- rom_cartridge.cpp
        |   `-- rom_cartridge.h
        |-- common
        |   |-- DialogOps.cpp
        |   |-- DialogOps.h
        |   |-- FileOps.h
        |   |-- Fileops.cpp
        |   |-- logger.cpp
        |   `-- logger.h
        |-- core
        |   |-- cartridge.cpp
        |   |-- cartridge.h
        |   |-- cartridge_capi.h
        |   |-- cartridge_context.h
        |   |-- cartridge_factory.h
        |   |-- detail
        |   |   `-- exports.h
        |   |-- interrupts.h
        |   `-- limits.h
        |-- devices
        |   |-- becker
        |   |   |-- beckerport.cpp
        |   |   `-- beckerport.h
        |   |-- rom
        |   |   |-- banked_rom_image.cpp
        |   |   |-- banked_rom_image.h
        |   |   |-- rom_image.cpp
        |   |   `-- rom_image.h
        |   `-- rtc
        |       |-- cloud9.cpp
        |       |-- cloud9.h
        |       |-- oki_m6242b.cpp
        |       `-- oki_m6242b.h
        `-- utils
            |-- cartridge_loader.cpp
            |-- cartridge_loader.h
            |-- configuration_serializer.cpp
            |-- configuration_serializer.h
            |-- critical_section.h
            |-- dll_deleter.h
            |-- filesystem.cpp
            |-- filesystem.h
            |-- winapi.cpp
            `-- winapi.h

Note: the use of vcc subdirectory for sources is to prevent name clashes
with include files.

I created a local branch to see how difficult it would be to make this change

First I changed file names and locations:
renamed libcommon/src/ to libcommon/vcc/
moved libcommon/include/* to libcommon/vcc/
deleted libcommon/include
In libcommon/vcc moved:
DialogOps.cpp Fileops.cpp logger.cpp to libcommon/vcc/common

Next I fixed .props and .vcxproj files:
In vcc-base.props:
replace
$(SolutionDir)libcommon/include
with
$(SolutionDir)libcommon

in libcommon/libcommon.vcxproj and libcommon.vcxproj.filters:
replace Include="src with Include="vcc vim: %s/"src\/"vcc\/
replace Include="include\vcc with Include="vcc vim: %s/="include\vcc/="vcc/
change:
<ClCompile Include="vcc\DialogOps.cpp"
<ClCompile Include="vcc\Fileops.cpp"
<ClCompile Include="vcc\logger.cpp"
to:
<ClCompile Include="vcc\common\DialogOps.cpp"
<ClCompile Include="vcc\common\Fileops.cpp"
<ClCompile Include="vcc\common\logger.cpp"

I tested a full build and new libcommon organization builds clean with no other changes, no sources needed to be changed. None of the files that were moved were changed so when I committed these changes git recognized them as renames rather than deletions and additions.

[ChetSimpson]

The current directory structure of libcommon was chosen for a specific reason and purpose. Aside from being common (and generally recommended for libraries or providing services to other components) it ensures the separation of public declarations and definitions provided to third parties and the private declarations and definitions that are internal to the library itself. Everything in libcommon/include/vcc is for public consumption, everything in libcommon/src is not.

[ChetSimpson]

RE: "how we choose to do things" This project is not controlled by some idealistic industry standard. It is controlled by those who manage it. This forum is a great place to hash out what we should do in that regard going forward.

Then why did you bring it up by saying "I could point to standards that...". What are the standards that you and not the group were referring to?

I do not use an IDE to develop VCC. 100% of my work is done on a text console using stock vim editor. There are no 'buttons' to click on to jump to a definition. That is the way I choose to do things. Because you choose to use an IDE should not force anyone else to.

So the root cause of the problem was your choice in development, which AFAIK is an edge case for this situation and no longer a concern.

[ChetSimpson]

RE: "it could be harder thing to change down the line."

How would it be harder to change down the line?

[ejaquay]

I want to make VCC development a colaborative effort. Ideally all team members are involved in decision making and their input is encouraged and accepted. There should be no "edge cases" to be ignored.

I do not plan to change the way the headers in libccommon are currently organized because it is not a big enough deal to disrupt our process which so far has been working well enough.

[ChetSimpson]

I want to make VCC development a colaborative effort. Ideally all team members are involved in decision making and their input is encouraged and accepted. There should be no "edge cases" to be ignored.

You're working on a project traditionally developed with Visual Studio but have chosen to use an archaic environment that is apparently lacking. My expectation is that if someone chooses a development environment like you have then they should be competent enough to respond to and account for changes like you have had to. Since the rest of us were not involved in that decision there's no obligation to have any concern nor would I do anything to shape the project just to accommodate it.

[ejaquay]

Visual Studio's IDE is easy enough to use. I just choose not to use it unless necessary because it is a Microsoft crutch that hides too many details about how things are put together.
Vim is not archaic. The current stable release of Vim is version 9.1.1577, released on July 21, 2025. The most recent version, Vim 9.1.1908, was announced on November 6, 2025.

[ejaquay]

Regarding libcommon dll vs static. As a developer a DLL is easier to deal with. But the most important thing to focus on is the VCC user experiance. My worry is publishing a version with an different type of DLL and the possible user confusion it could cause. Perhaps my concern could be mitigated by simply renaming libcommon.dll to libcommon.vcc or some such. That at least would prevent it from being offered as an option for loading as a hardware pak.