Enable the parallel feature by default

It is not practical to go through every single dependency and enable the parallel feature for them. This should be a default feature.

Wouldn't enabling this feature once for this library enable it for everything though? It seems worse to force people to go to each dependency and find the feature flag to disable cc's default features, assuming they even expose such functionality.

Well, if someone wants to make their build intentionally single-threaded, they can set JOBS to 1.

True, but enabling the parallel feature will also pull in a new dependency. If this dependency is unwanted, it becomes much harder to remove it since default features are difficult to disable.

So, you mean people want to make the build n times slower just not to grab such a small build dependency? I haven't seen a build system that intentionally makes the build slower.

Including a build dependency when it isn't needed will increase the build time, which will slow down the overall build. Some builds will also not benefit from a parallel build. As an example, using the parallel feature in a debug build of a project that uses rusqlite increases the overall build time by about 1.5 seconds on my machine. Opting into the parallel feature is also as simple as enabling it in the top-level crate as a build dependency, which will enable it for all crates in the tree which use cc as a build dependency. In contrast, if the parallel feature were default, the user would need to manually patch every crate in their tree to not use cc's default features. Since it is far easier to enable a feature than it is to remove a default feature, I think that parallel should not be default so that users can make a choice as to whether to pull extra code for a parallel build or not.

It is not possible to enable a feature when you run cargo install . Run cargo install outdated and wait for the build to happen very slowly.

The time it takes to build job server is nothing when compared to the time it takes to build cargo. When designing a tool, you should consider the average experience and not the exceptions. In most cases, the parallel build has visible benefits.

It is possible to enable features for a cargo install build with the --features flag. One could add a feature to their binary to easily allow users to make their build parallel while installing, even by default.

I'm assuming you mean cargo install cargo-outdated when you say cargo install outdated. That build should already have parallel enabled; libgit2-sys turns it on since it has a large number of files that need to be built. I think this is how it should be: libraries that have a large number of files to compile with cc can opt-in to a faster, parallel build (forcing it for all other crates as well).

I'm also not sure that a parallel build is a good for for the average experience. Some crates rely on cc just to find build tools, like cmake or jemalloc-sys. Others only need to compile a few files, like signal-hook and libsqlite3-sys. Others are forced to use it as a form of platform detection, like backtrace or findshlibs. I'm just not sure making parallel the default is a good idea as cc is used as more than a method of compiling large numbers of c files. For a ubiquitous dependency like cc, enabling the parallel feature by default would almost be the same as removing the feature and merging the functionality into cc.