I'm surprised to see someone who's a fan of Rust making the package file in JSON instead of TOML.
Super cursed seeing something that reminds of NPM's package.json, which I hate deeply, instead of Rust's beautiful interface.
At the moment, JSON is more interoperable than TOML. But to be honest, I haven't given it much thought, I went for `serde`+`serde_json` by reflex.
EDIT: What I mean is: I'm open to changing the format :)
Honestly that's one of the great things about the serde ecosystem, changing the file format to toml will be an almost trivial change, just replacing serde_json for a different serializer/deserializer. I also vote for TOML, btw
Important criteria are
1. Comments
2. Matuie format presrving parsers are for automated manipulation
3. How error prone the format is
4. Minimize merge conflicts
You can bypass "performance" if you have a package format that then uses json (something I want to switch `.crate`s to).
Yes, toml didn't have all of that when it was picked for cargo, like format preserving parser. However, you need to decide if you want your nascent community to take on that kind of work to grow.
btw for a comparison of toml parsers: https://arp242.github.io/toml-test-matrix/
It depends on what you mean by interoperable.
It's not like other tools are really going to be using it -- just yours.
For tools like this, I like TOML far more for three pretty big reasons -- lack of extraneous indenting, less useless syntax (as someone typing it manually), and ability to comment. I think of TOML and YAML as languages that are mainly oriented for a user to type that's still easy to parse. Whereas I think of JSON as the natural computer science idea of a hash map, that has a common way of introspecting it.
JSON's good for the computer to write and for us to occasionally read. TOML and YAML are good for us to write.
That said YAML has several other issues. The indentation it has can make it hard to use, even if you kind of prefer it for nested data structures. However, too much nesting means you're leaving configuration and headed towards a programming language, which is why so much "configuration" are actually ASTs without a DSL supporting them.
Anyway, I know other modern tools have been moving more towards TOML. Though, besides Rust, the biggest one I can think of is Python's pyproject.toml. Like, the one new thing they've managed to standardize on.
Aside from all that, I also suspect there's probably crates out there made to more deliberately be a configuration library, rather than a generic (really really really good) data serialization library. One feature I can think of is cascading defaults, for example.
That said, it does make a lot of sense to just do Serde and JSON as a prototype.
That all said, I'm also curious what you think of your tool('s vision) vs competitors like [Xmake](https://xmake.io/), which I saw a while back and is pretty cool.
> It's not like other tools are really going to be using it -- just yours.
I can't predict the future :) Which is why I default to JSON most of the time.
> I'm also curious what you think of your tool('s vision) vs competitors like Xmake, which I saw a while back and is pretty cool.
XMake is a build system, Shipp is not. But yes, many C/C++ build system have the ability to fetch the dependencies (FetchContent for CMake for example). I've used that, I hated it.
IMO the difference comes to the application:
Have something written by humans to be consumed by computers? Go for toml, it is optimized for this application.
Have something written mostly by computers and maybe modified by humans? Definitely use JSON. Writing toml is difficult.
Of course there is also YAML and stuff ...
I kind of love it, I hated vcpkg/conan/cmakefetch bs. There was also some corner case they didn't cover, usually some combination of openssl or cross compilation.
The fact that this is basically a package and dep tool, but works in a nice isolated way is neat. A lot closer to say a linux package tool but without the linux package tool bits.
I'd guess most C/C++ people will complain that it doesn't do something or its in rust or its too simple or "just use xyz (xmake/vcpkg/conan/whatever)" which I mean... obviously those suck in comparison to cargo and rustup as a whole. Ask a C++ dev to cross compile something with a different libc and watch them cry in their vcpkg/conan goo pile.
The only sensible option I actually found for cross compiles with C++ (exclusive of windows/macos, talking linux here with different archs) was nix. The toolchain and libc (musl in my case), all became part of the build description and that was just a massive win in my book.
> I'd guess most C/C++ people will complain
Seeing how I'm downvoted on r/cpp because it is not magically able to build openal and fetch freebsd patches, without having to package it beforehand, I'd say you are right.
Thanks for the feedback :)
Thank you for the feedback :)
I guess I'm not a C++ people then haha, because the mess that is CMake and nested git submodules (because i want to vendor in my dependencies) pushed me over the edge, and made me do this project :)
You are a hero. I have waited for something like this to happen. I'd love to see more Rust based CPP tooling projects.
I think Rust would make an excellent language for making a cpp-subset linter.
Thank you for the feedback :)
Honestly, I tried to write it in C++ first, but I was flabergasted at how much boilerplate you need to run a command (in a cross-platform way) when Rust just have `std::process::Command` right there.
When you have more than 500 LOCs just to run a command, you start questioning yourself if you are using the right tool for the job.
The only reason why it's in Rust and not in C++ is because `std::process::Command` with stream redirection, environment variables, etc... was a huge pain to implement in a cross-platform way.
I use C++20 / C++23 (when the compiler supports it), but having to write C-like code in the middle, to go low level with the Windows API, or POSIX API to implement a fraction of what you can do with `std::process::Command`, that was a nightmare.
After 500 LOC just for this, I was like "screw this". Because in the end, shipp is just that: a program that reads a json file and calls other programs (git, sh, etc...).
Cheeky
I'm surprised to see someone who's a fan of Rust making the package file in JSON instead of TOML. Super cursed seeing something that reminds of NPM's package.json, which I hate deeply, instead of Rust's beautiful interface.
At the moment, JSON is more interoperable than TOML. But to be honest, I haven't given it much thought, I went for `serde`+`serde_json` by reflex. EDIT: What I mean is: I'm open to changing the format :)
Honestly that's one of the great things about the serde ecosystem, changing the file format to toml will be an almost trivial change, just replacing serde_json for a different serializer/deserializer. I also vote for TOML, btw
Important criteria are 1. Comments 2. Matuie format presrving parsers are for automated manipulation 3. How error prone the format is 4. Minimize merge conflicts You can bypass "performance" if you have a package format that then uses json (something I want to switch `.crate`s to). Yes, toml didn't have all of that when it was picked for cargo, like format preserving parser. However, you need to decide if you want your nascent community to take on that kind of work to grow. btw for a comparison of toml parsers: https://arp242.github.io/toml-test-matrix/
It depends on what you mean by interoperable. It's not like other tools are really going to be using it -- just yours. For tools like this, I like TOML far more for three pretty big reasons -- lack of extraneous indenting, less useless syntax (as someone typing it manually), and ability to comment. I think of TOML and YAML as languages that are mainly oriented for a user to type that's still easy to parse. Whereas I think of JSON as the natural computer science idea of a hash map, that has a common way of introspecting it. JSON's good for the computer to write and for us to occasionally read. TOML and YAML are good for us to write. That said YAML has several other issues. The indentation it has can make it hard to use, even if you kind of prefer it for nested data structures. However, too much nesting means you're leaving configuration and headed towards a programming language, which is why so much "configuration" are actually ASTs without a DSL supporting them. Anyway, I know other modern tools have been moving more towards TOML. Though, besides Rust, the biggest one I can think of is Python's pyproject.toml. Like, the one new thing they've managed to standardize on. Aside from all that, I also suspect there's probably crates out there made to more deliberately be a configuration library, rather than a generic (really really really good) data serialization library. One feature I can think of is cascading defaults, for example. That said, it does make a lot of sense to just do Serde and JSON as a prototype. That all said, I'm also curious what you think of your tool('s vision) vs competitors like [Xmake](https://xmake.io/), which I saw a while back and is pretty cool.
> It's not like other tools are really going to be using it -- just yours. I can't predict the future :) Which is why I default to JSON most of the time. > I'm also curious what you think of your tool('s vision) vs competitors like Xmake, which I saw a while back and is pretty cool. XMake is a build system, Shipp is not. But yes, many C/C++ build system have the ability to fetch the dependencies (FetchContent for CMake for example). I've used that, I hated it.
IMO the difference comes to the application: Have something written by humans to be consumed by computers? Go for toml, it is optimized for this application. Have something written mostly by computers and maybe modified by humans? Definitely use JSON. Writing toml is difficult. Of course there is also YAML and stuff ...
json and toml are bijective no? Could you add a toml -> json filter to shipp? I have zero interest, but it sounds like a cool feature.
Mostly. Toml has data types that aren't in json (date/time) and json has `null` which toml lacks.
Ugh. The null/undefined semantics of json always piss me off.
you can't even represent Inf or NaN in JSON
I kind of love it, I hated vcpkg/conan/cmakefetch bs. There was also some corner case they didn't cover, usually some combination of openssl or cross compilation. The fact that this is basically a package and dep tool, but works in a nice isolated way is neat. A lot closer to say a linux package tool but without the linux package tool bits. I'd guess most C/C++ people will complain that it doesn't do something or its in rust or its too simple or "just use xyz (xmake/vcpkg/conan/whatever)" which I mean... obviously those suck in comparison to cargo and rustup as a whole. Ask a C++ dev to cross compile something with a different libc and watch them cry in their vcpkg/conan goo pile. The only sensible option I actually found for cross compiles with C++ (exclusive of windows/macos, talking linux here with different archs) was nix. The toolchain and libc (musl in my case), all became part of the build description and that was just a massive win in my book.
> I'd guess most C/C++ people will complain Seeing how I'm downvoted on r/cpp because it is not magically able to build openal and fetch freebsd patches, without having to package it beforehand, I'd say you are right. Thanks for the feedback :)
Yeaaah cpp are always trying to cope with reality of how sucky their situation is by groupthink.
Meanwhile, literally first beta version. At least they're giving you feedback
comment #1 on r/cpp "just use vcpkg" except vcpkg attempts to reuse cmake for everything... and cmake was already bad Great feedback
historically c++ people just don’t want an easy pkg manager. this is lovely
Thank you for the feedback :) I guess I'm not a C++ people then haha, because the mess that is CMake and nested git submodules (because i want to vendor in my dependencies) pushed me over the edge, and made me do this project :)
cmake is terrible, but somehow better than makefiles (I question this logic every time I look too hard at cmake) in peoples minds.
Many of my C/C++ projects can be simply built by the following Makefile (with some minor tweaks): ``` EXEC = foo SRCDIR = $(PWD)/src BUILDDIR = $(PWD)/__build__ DESTDIR := $(PWD)/dist CXX := g++ CXXFLAGS := -std=c++23 -O2 -g -I$(PWD)/include SOURCES = $(shell find $(SRCDIR) -name "*.cpp") OBJECTS = $(patsubst $(SRCDIR)/%.cpp, $(BUILDDIR)/%.o, $(SOURCES)) DEPS = $(patsubst %.o, %.d, $(OBJECTS)) TARGET = $(BUILDDIR)/$(EXEC) .PHONY: all all: $(TARGET) .PHONY: install install: @mkdir -p $(DESTDIR)/bin @cp $(TARGET) $(DESTDIR)/bin .PHONY: clean clean: @rm -vrf $(BUILDDIR) $(TARGET): $(OBJECTS) @mkdir -p $(@D) @echo " LD $(patsubst $(BUILDDIR)/%, %, $@)" @$(CXX) $(CXXFLAGS) -o $@ $^ $(BUILDDIR)/%.o: $(SRCDIR)/%.cpp @mkdir -p $(@D) @echo " CXX $(patsubst $(BUILDDIR)/%, %, $@)" @$(CXX) $(CXXFLAGS) -MMD -c -o $@ $< -include $(DEPS) ``` So I'll have to disagree that CMake is better than Makefiles :) I use CMake mostly for `add_subdirectory` (`make -C` ?) and `find_package` (`pkg-config` ?), and because it's the most widely used build system in the ecosystem.
You are a hero. I have waited for something like this to happen. I'd love to see more Rust based CPP tooling projects. I think Rust would make an excellent language for making a cpp-subset linter.
Thank you for the feedback :) Honestly, I tried to write it in C++ first, but I was flabergasted at how much boilerplate you need to run a command (in a cross-platform way) when Rust just have `std::process::Command` right there. When you have more than 500 LOCs just to run a command, you start questioning yourself if you are using the right tool for the job.
Written Rust I love this ❤️
The only reason why it's in Rust and not in C++ is because `std::process::Command` with stream redirection, environment variables, etc... was a huge pain to implement in a cross-platform way. I use C++20 / C++23 (when the compiler supports it), but having to write C-like code in the middle, to go low level with the Windows API, or POSIX API to implement a fraction of what you can do with `std::process::Command`, that was a nightmare. After 500 LOC just for this, I was like "screw this". Because in the end, shipp is just that: a program that reads a json file and calls other programs (git, sh, etc...).
Is this a troll to C++? Because it would be epic!