3 ms·

Do you have an RSS or Atom feed so I can subscribe and be notified when Rig is available. Anyways, I’m looking forward to more options in this space. The curre

Do you have an RSS or Atom feed so I can subscribe and be notified when Rig is available. Anyways, I’m looking forward to more options in this space. The current pattern of rebuilding everything from scratch every time in a non deterministic way is the gross reality of GitHub Actions and Dockerfiles. It would be great to have more people working on a more cacheable build system. That said, I wonder what Rug can do about IDE integration. Specifically several IDEs (visual studio and Xcode come to mind) need their own project file format to be able to understand how to interpret source code. One approach that Buck did is to generate those files. But it is always a source of friction when trying to get an IDE to integrate smoothly with an additional build system.

gavinhoward 3y ago
https://yzena.com/index.xml https://yzena.com/index.xml But I can email you directly if you wish. > It would be great to have more people working on a more cacheable build system. Rig is not that yet, unfortunately. I don't want to get your hopes up. It can't even do incremental builds yet. And while it has multi-threading, I haven't tested it. This is very alpha software. > That said, I wonder what Rug can do about IDE integration. Specifically several IDEs (visual studio and Xcode come to mind) need their own project file format to be able to understand how to interpret source code. One approach that Buck did is to generate those files. But it is always a source of friction when trying to get an IDE to integrate smoothly with an additional build system. Generating those files was my plan, but friction is not good. Can you describe the friction and its source? I'll do some rethinking and redesign. Thank you for your interest!
- MarkSweep 3y ago
  > Rig is not that yet, unfortunately. I don't want to get your hopes up. No worries, this space has so much inefficiency that I'm sure you will eventually start chipping away at it. > Can you describe the friction and its source? I'll do some rethinking and redesign. Some software ecosystems already have their own build tools. Often these build systems are intertwined with IDE support. So care must be taken to ensure the IDE still functions as developers expect. If you ignore the functioning of the IDE, developers will balk at adopting the new build tool. There is some prior art for generating files that an IDE can understand: https://buck.build/command/project.html https://buck.build/command/project.html https://github.com/bazelbuild/tulsi https://github.com/bazelbuild/tulsi Interfacing existing build tools into a meta build tool can be difficult to do efficiently, but I’ve run out of time for talking about that tonight.

gavinhoward 3y ago

https://yzena.com/index.xml https://yzena.com/index.xml But I can email you directly if you wish. > It would be great to have more people working on a more cacheable build system. Rig is not that yet, unfortunately. I don't want to get your hopes up. It can't even do incremental builds yet. And while it has multi-threading, I haven't tested it. This is very alpha software. > That said, I wonder what Rug can do about IDE integration. Specifically several IDEs (visual studio and Xcode come to mind) need their own project file format to be able to understand how to interpret source code. One approach that Buck did is to generate those files. But it is always a source of friction when trying to get an IDE to integrate smoothly with an additional build system. Generating those files was my plan, but friction is not good. Can you describe the friction and its source? I'll do some rethinking and redesign. Thank you for your interest!

MarkSweep 3y ago
> Rig is not that yet, unfortunately. I don't want to get your hopes up. No worries, this space has so much inefficiency that I'm sure you will eventually start chipping away at it. > Can you describe the friction and its source? I'll do some rethinking and redesign. Some software ecosystems already have their own build tools. Often these build systems are intertwined with IDE support. So care must be taken to ensure the IDE still functions as developers expect. If you ignore the functioning of the IDE, developers will balk at adopting the new build tool. There is some prior art for generating files that an IDE can understand: https://buck.build/command/project.html https://buck.build/command/project.html https://github.com/bazelbuild/tulsi https://github.com/bazelbuild/tulsi Interfacing existing build tools into a meta build tool can be difficult to do efficiently, but I’ve run out of time for talking about that tonight.