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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list
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.

In the meanwhile W10 is sorted again, but the whole lot is just getting increasingly fragile, while Fedora is getting increasingly solid (no bt-headphone stuttering, while connected to wifi and look at that brightness/crispness of that Full HD screen I have never seen before under W10!), the latter not upping complexity (2'001 packages to download and install to get from F30 to F31, but that's not complexity).

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.

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.

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 (want to) use vcpkg.

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.

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 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.

As usual my write-ups are a bit messy, I am learning I'm slightly dyslexic, sorry for the endless comma's.

Thanks in advance for any ideas submitted.

I would not mind partnering with somebody else, ya'll have a nice day,

degski
--
@systemdeg
"We value your privacy, click here!" Sod off! - degski
"Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

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

Boost - Users mailing list


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?


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users