4 ms·

cc main.c is about as easy as it gets, no?

linkdd 5y ago
Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms. Then add configuration options for conditional compilation, and a build system to define them properly. Then use the configuration options of your dependencies in your build system. Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime. cc main.c is as easy as it gets when you rewrite everything from scratch. cargo is as easy as it gets when you want an ecosystem.
- snovv_crash 5y ago
  Add a closed source dependency in Rust and see how far cargo takes you.
  - linkdd 4y ago
    I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0]. Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases? [0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
    - snovv_crash 4y ago
      No, I want a closed source Rust dependency. Otherwise it's going through a C API and I lose all of the benefits of using Rust. Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies. Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.
      - linkdd 4y ago
        A .rlib file then, that you can then add with: RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"
noselasd 5y ago
Yes, but only for tiny tools or toys. Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.

Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms. Then add configuration options for conditional compilation, and a build system to define them properly. Then use the configuration options of your dependencies in your build system. Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime. cc main.c is as easy as it gets when you rewrite everything from scratch. cargo is as easy as it gets when you want an ecosystem.

snovv_crash 5y ago
Add a closed source dependency in Rust and see how far cargo takes you.
- linkdd 4y ago
  I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0]. Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases? [0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
  - snovv_crash 4y ago
    No, I want a closed source Rust dependency. Otherwise it's going through a C API and I lose all of the benefits of using Rust. Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies. Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.
    - linkdd 4y ago
      A .rlib file then, that you can then add with: RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"

noselasd 5y ago

Yes, but only for tiny tools or toys. Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.