I'll try to answer to the best of my knowledge, even if I'm far from a build process expert.

1. To make things clear: Unix make and SCons are totally different beasts. Unix make builds code, just like the Visual Studio toolchain does. SCons does many more things, it can manage most of the whole build process, so that's not something you call everytime you make a little code change. Typically, when changing code:

   • Most of the time, just running the compiler + linker is enough
   • When adding/removing/renaming source files, it's necessary to close the IDE and run CMake, Premake or similar to recreate your projects (if such a tool is in use)
   • And that's only when doing a code change that isn't compatible with current data that the data needs to be binarized again

2. If you're talking about a whole build process, including binarizing data, creating installation script, etc., then no that's usually not something that's done from an IDE. It's usually managed by some continuous integration software, or just a bunch of custom scripts, run automatically overnight for big projects.

3. I won't go into folder structure, as there is no standard for that, just follow your instinct on what you feel is best. Just make sure you have a clear distinction between source code/assets and generated stuff, this helps keeping version control clean. What a build process does usually is as follows:

   • Generate the projects for all platforms & configurations
   • Build the code for each project
   • Binarize all data
   • Package: create disc images, installation scripts...
   • Run automated tests
   • In case of failure, report errors
   • In case of success, archive the build somewhere

I'll try to answer to the best of my knowledge, even if I'm far from a build process expert.

1. Typically, when changing code:

   • Most of the time, just running the compiler + linker is enough
   • When adding/removing/renaming source files, it's necessary to close the IDE and run CMake, Premake or similar to recreate your projects/makefile/etc. (if such a tool is in use)
   • And that's only when doing a code change that isn't compatible with current data that the data needs to be binarized again

2. If you're talking about a whole build process, including binarizing data, creating installation script, etc., then no that's usually not something that's done from an IDE. It's usually managed by some continuous integration software, or just a bunch of custom scripts, run automatically overnight for big projects.

3. I won't go into folder structure, as there is no standard for that, just follow your instinct on what you feel is best. Just make sure you have a clear distinction between source code/assets and generated stuff, this helps keeping version control clean. What a build process does usually is as follows:

   • Generate the projects for all platforms & configurations
   • Build the code for each project
   • Binarize all data
   • Package: create disc images, installation scripts...
   • Run automated tests
   • In case of failure, report errors
   • In case of success, archive the build somewhere

I'll try to answer to the best of my knowledge, even if I'm far from a build process expert.

1. To make things clear: Unix make and SCons are totally different beasts. Unix make builds code, just like the Visual Studio toolchain does. SCons is one step before, it builds projects, just like the Autotools do in the Unix world. An SCons script could generate for instance: makefiles for Unix builds, Visual Studio projects for Windows builds, and Xcode projects for Mac builds. So yeah, for SCons-like scripts, that's typically something you run once to generate your project(s), and then any time you add/remove/rename source code files. As it modifies projects files, you typically have to close your IDE before running them.

2. If you're talking about a whole build process, including binarizing data, creating installation script, etc., then no that's usually not something that's done from an IDE. It's usually managed by some continuous integration software, or just a bunch of custom scripts, run automatically overnight for big projects.

3. I won't go into folder structure, as there is no standard for that, just follow your instinct on what you feel is best. Just make sure you have a clear distinction between source code/assets and generated stuff, this helps keeping version control clean. What a build process does usually is as follows:

   • Generate the projects for all platforms & configurations (Scons)
   • Build the code for each project (make, Visual Studio build...)
   • Binarize all data
   • Package: create disc images, installation scripts...
   • Run automated tests
   • In case of failure, report errors (via e-mail, plugins - e.g. as with CruiseControl)
   • In case of success, archive the build somewhere

I'll try to answer to the best of my knowledge, even if I'm far from a build process expert.

1. To make things clear: Unix make and SCons are totally different beasts. Unix make builds code, just like the Visual Studio toolchain does. SCons does many more things, it can manage most of the whole build process, so that's not something you call everytime you make a little code change. Typically, when changing code:

   • Most of the time, just running the compiler + linker is enough
   • When adding/removing/renaming source files, it's necessary to close the IDE and run CMake, Premake or similar to recreate your projects (if such a tool is in use)
   • And that's only when doing a code change that isn't compatible with current data that the data needs to be binarized again

2. If you're talking about a whole build process, including binarizing data, creating installation script, etc., then no that's usually not something that's done from an IDE. It's usually managed by some continuous integration software, or just a bunch of custom scripts, run automatically overnight for big projects.

3. I won't go into folder structure, as there is no standard for that, just follow your instinct on what you feel is best. Just make sure you have a clear distinction between source code/assets and generated stuff, this helps keeping version control clean. What a build process does usually is as follows:

   • Generate the projects for all platforms & configurations
   • Build the code for each project
   • Binarize all data
   • Package: create disc images, installation scripts...
   • Run automated tests
   • In case of failure, report errors
   • In case of success, archive the build somewhere