> No I claimed you are incompetent because you can't deal with a `.lib` file that contains the output from more than one source file.
None of the work I do cares about the actual output artifacts. I care, almost exclusively, about the representation of the build graph itself. That work cannot be done if I don't have a build graph to analyze, which I don't if you do things like glob files together.
I've seen the simple act of untangling a globbed dependency to the various isolated files reduce the size of an output artifact by gigabytes.
> any language that doesn't have those features is not a mature programming language
You're calling literally every language that doesn't use the c-linker an immature language. Which may include c++17-with-modules, though I don't know that for certain.
> javascript
Javascript doesn't do what you're talking about though. At least not if you do any fancy precompilation/tree-shaking to your js at compile time. If all you're doing is copying the files, then sure, but as soon as you want to do useful things like, for example, run a typescript or closure analysis on your files, or generate js from typescript, or compile and minify your js, it will get a whole heck of a lot faster when you use more isolated build targets[0]. I know because our JS teams went to a lot of work to make js builds faster by taking advantage of this information.
> I've seen the simple act of untangling a globbed dependency to the various isolated files reduce the size of an output artifact by gigabytes.
And I don't take issue with what are obviously exceptional cases. What you are describing is not "I put togeather 5 related files" it's like "I globbed a file I wasn't supposed to".
> You're calling literally every language that doesn't use the c-linker an immature language. Which may include c++17-with-modules, though I don't know that for certain.
Uhhhh, I don't think you understand how the feature in question functions. I am simply talking about the -M option family of gcc (and similar commands for other compilers). Which provides a dependency tree for C++ files.
> At least not if you do any fancy precompilation/tree-shaking to your js at compile time.
I think it's actually the opposite. Those are the same tools that provide the reflection features in question (or some other AST parsing library)... then you write a two line lambda and feed that in over an interpreter. Boom list of files.
None of the work I do cares about the actual output artifacts. I care, almost exclusively, about the representation of the build graph itself. That work cannot be done if I don't have a build graph to analyze, which I don't if you do things like glob files together.
I've seen the simple act of untangling a globbed dependency to the various isolated files reduce the size of an output artifact by gigabytes.
> any language that doesn't have those features is not a mature programming language
You're calling literally every language that doesn't use the c-linker an immature language. Which may include c++17-with-modules, though I don't know that for certain.
> javascript
Javascript doesn't do what you're talking about though. At least not if you do any fancy precompilation/tree-shaking to your js at compile time. If all you're doing is copying the files, then sure, but as soon as you want to do useful things like, for example, run a typescript or closure analysis on your files, or generate js from typescript, or compile and minify your js, it will get a whole heck of a lot faster when you use more isolated build targets[0]. I know because our JS teams went to a lot of work to make js builds faster by taking advantage of this information.
[0]: https://news.ycombinator.com/item?id=20975227