3 ms·

Or one of its major advantages. Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating

Or one of its major advantages. Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? I'd love to use a tool that looks nicer, but there is nothing (to my knowledge, I'd love to be proven wrong!) that can do what CMake does with the same breadth and transparency.

weberc2 9y ago
> Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? You have the problem backwards. IDEs wouldn't need distinct project files if build systems could reasonably describe the project structure out of the box. There is no need for every tool to know about every other tool. This is a solved problem in most modern programming languages.
- lomnakkus 9y ago
  > This is a solved problem in most modern programming languages. No it's not. Not even close. Just out of curiosity what what's your current IDE?
  - weberc2 9y ago
    It absolutely is. My "IDE" is vim. It understands projects in Rust, Purescript, and Go by installing a single plugin. Zero configuration. The same works for VSCode.
    - lomnakkus 9y ago
      > It absolutely is. No, it really isn't, but... have fun whatever you're doing. :)
- 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.

weberc2 9y ago

> Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? You have the problem backwards. IDEs wouldn't need distinct project files if build systems could reasonably describe the project structure out of the box. There is no need for every tool to know about every other tool. This is a solved problem in most modern programming languages.

lomnakkus 9y ago
> This is a solved problem in most modern programming languages. No it's not. Not even close. Just out of curiosity what what's your current IDE?
- weberc2 9y ago
  It absolutely is. My "IDE" is vim. It understands projects in Rust, Purescript, and Go by installing a single plugin. Zero configuration. The same works for VSCode.
  - lomnakkus 9y ago
    > It absolutely is. No, it really isn't, but... have fun whatever you're doing. :)
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.