So you may have noticed that OIIO (and OSL) do something slightly weird -- the build area is not just in build/, but specifically is in build/ARCH where ARCH is a combination of machine architecture and mode, for example linux, linux.debug, macosx, windows, etc. (And same for dist -> dist/windows, dist/linux, etc.).
Why? Well, I can probably trace this back a couple decades. No, not for OIIO per se, that was before its time, I'm just talking about having borrowed the way I set up builds habitually, a long long time ago. Dinosaurs roamed the earth, machines were slow and had one CPU core, there was no ccache, so having all the build variants co-exist at all times as non-interfering siblings could save a lot of rebuild time. If I wanted to switch between them, it was too expensive to have to make clean and rebuild from scratch. But is any of that meaningful in the 21st century world of flying cars and moon bases? I've got oodles of fast cores and can do a first-time compile in a minute or two, a subsequent compile in a few seconds (thanks ccache!). If I want to switch from release to debug build and back, make clean and start fresh doesn't even take long enough to get a coffee. And I can't remember the last time I needed to build two OS architectures in the same directory structure or account. And the real killer is, my vestigial tail of a build layout violates the expectation of every CMake user by being one layer too deep. Thus, it's probably not worth the trouble of having to document the weirdness. So... What do people think about transitioning to just using build/ and dist/ in the standard way? It means that to switch between Debug and Release means a rebuild, but what you get in return is a build whose layout and techniques are more in line with the rest of the cmake universe. Everybody who builds frequently enough to care has multicore machines and ccache, right? No immediate plans, just feeling this issue out. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
