Re: yabs: Yet Another Build System, seeking input/micro-team member

From: Raymond Burkholder (ray_at_[hidden])
Date: 2020-03-03 16:08:23

On 2020-03-03 8:14 a.m., degski via Boost-users wrote:
> Hi All,
>
> Recently, I have started to get more and more dis-enchanted with 
> Windows. The OS is being dumbed down every step of the way, while the 
> internal complexity keeps going up. The latest and the most fun 
> break-down to date of Windows was last week, the story is long, but in 
> the end in came down to not being able to open the system-settings in 
> the W10-style settings. The W7-style settings are also available, but 
> the API's are overlapping but neither is a super-set of the other, so 
> no way to fix the settings, because the settings themselves are broken 
> (had something to do with display-drivers), way to go MS.
As a consultant, I saw this dumbing down a long time ago and created no 
end of frustration with troubleshooting.  I guess that is what the event 
log is for, but that has its own issues.

> I want to move to Fedora, and for now I'm dual-booting. This involves 
> dumping VS in favor of VSCode (which is flat-packed for Fedora and 
> compadres and is also available on OSX, so there is potentially a 
> large audience), no acceptable other options (other than the one(s) 
> VSCode is based on) are available AFAIKS, gnome-builder seems to have 
> different goals from VS and it appears to be early days.
Yep, after looking at many of those including eclipse and netbeans, I 
have ended up with VSCode.
> VSCode seems (to me) to be like the best thing since sliced-bread, iff 
> you are writing Python or Rust (Prolog works nicely as well), but C++ 
> is only partially great, the language server works very nicely, code 
> completion, good, but the build-system, proposed, is cumbersome. I 
> would like VSCode to work more like VS, but without the complexity, 
> the endless clicking, drop-down boxes etc etc.
I might suggest thinking about using CMake.  it takes a little getting 
used to, and has a bit of learning curve, but it has good integration 
with VSCode.  I use CMake 0.0.17 (at the time of this writing) and CMake 
Tools 1.3.1 (ditto).
> It comes down to writing json-files, which is good, but on a per 
> project basis. Having to do this on a per  project basis is a problem 
> (that's going backwards from using project-templates in VS, I now in 
> VS can create a new project in 3 seconds flat, and every detailed 
> setting (clang and vc) is set correctly and how **I** want it, and I 
> am running "Hello World!" (the default main in the template) in total 
> 10 secs, this very handy to try things out). I don't want to go 
> backwards. Therefore, I would like to do this on a repo-basis (the 
> only one I have), with, iff required, another json in the 
> project-folder (in the parent repo-folder), i.e.:
>
> /repos/
> /repos/repo.json
> /repos/project-one/
> /repos/project-one/project.json
> /repos/project-two/
> /repos/project-two/project.json
> /repos/ ...
I am not sure if I understand all of what you are attempting to do, but 
CMake can work with a primary projects and sub-projects.

> I (want to) use vcpkg.
If you decide to get into cross platform projects, vcpkg may not be the 
way to go.

> I structure my projects always the same, all build systems (to my 
> purpose) are basically an over-shoot on the one hand and overly fiddly 
> on the other hand.
Rather than re-inventing the wheel, maybe try CMake, or another 
established build system.  The structure can be as fiddly as you want, 
and is generally used in many projects.

> The task at hand, build the .cpp files in the root of the project 
> folder into one binary. The include files are either in the 
> vcpkg/installed/.../include folder or in a sub-include-folder in the 
> project. Libraries to link are either in vcpkg/installed/.../lib, or 
> vcpkg/installed/.../debug/lib. We are not talking rocket-science here, 
> I presume that many people have simple needs like this/me, or that if 
> building (adopting this structure) becomes easy enough people would 
> adopt such a structure.
I have several projects with multiple sub-projects, such as what you 
describe.  And isn't really rocket science, as you desire.

> I would like to have one json to rule them all, and one json to either 
> over-ride the defaults, or to add to the defaults, depending on 
> whether the setting is defined in the repo.json. The repo.json might 
> well be layered itself, to accommodate the various compilers, and/or 
> configuration. For the moment nlohman's json seems perfectly adequate 
> for the job, and it's certainly easy to use (and seems to just use 
> std::maps in a clever way, so it's easy to follow what's going on).
>
> It's all about merging, fusing, overlaying those json's as needed 
> (gonna be entertaining, making it smart), and pass that on to some 
> generic API for building. So a new compiler would mean to just add a 
> json-section, or a json-file, fill that with appropriate data 
> (possibly nothing, iff the default-defaults are good), and it should work.
>
> The current way VSCode is setup, means that this imaginary 
> build-system can be easily and readily included/used in VSCode (with 
> more json).
>
> Yes, just like the working name indicates YABS, it must be as simple 
> as possible, but no simpler.
>
> Any input is appreciated, but please refrain from arguing that BS-X 
> does this better (and exists) or BS-Y has a large crowd of followers 
> (and is used for a long period of time), that's water under the 
> bridge, I will pursue this, just to see how far one can get pushing 
> these initial ideas further.

Sorry.  Already did.  This comment should have come first.   But I'm not 
sure why you want to re-invent the wheel with something that already 
integrates with VSCode, and is maintained by Microsoft as a primary 
extension?