4 ms·
> IDEs wouldn't need distinct project files But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. > There is no
by geezerjay 9y ago
> IDEs wouldn't need distinct project files
But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates.
> There is no need for every tool to know about every other tool.
If you want your product to be supported by an IDE but you don't have any say on how that IDE is developed, the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files.
- weberc2 9y ago> But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. But they don't, and saying they're "imposed by reality" is not a compelling argument. They need information about a project; there is no reason that information needs to be generated by a build tool instead of the same files that the rest of the toolchain use. They may also need a file to save a user editor preferences, but there is no reason that needs to be the project metadata file. > the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files. This is patently false. Almost every interesting IDE is pluggable, so a single plugin is written and maintained for each programming language that supports a reasonable project metadata file. CMake is the odd exception which generates files for IDEs because the project metadata is buried in the mess of imperative glue code used to build the project in lieu of a proper build tool.