You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One issue described by @aseemr and @nikswamy was that the Wrapper files produced by --batch make all modules on the command line share the same internal state, such as counters to assign error codes to struct fields. This has the effect of having such fields of some module A appear in the Wrapper of a module B even if A and B do not depend on one another.
We should not keep two distinct build processes, one for --makefile and another for --batch. Eliminating the latter would make our code maintenance much easier.
Proposed Solution
I believe that a solution to this problem is to make --batch behave closer to --makefile, by actually making 3d call itself again on each task instead of performing internal function calls. The way I envision it is to take the tasks computed by GenMakefile and topologically sort them and execute them instead of printing them into a Makefile.
Non-goal: Parallelism
I do not intend to introduce parallelism here. I believe that parallelism should be deferred to a build system. While 3d support for GNU Make can already offer parallelism, I can understand that users may want more lightweight and portable solutions. For such users, I believe that #48 will answer them, because Ninja readily and smoothly supports parallelism while being very lightweight (less than half a megabyte), so much so that I could even include it in future EverParse binary packages (by virtue of Ninja's Apache 2 open-source license.)
The text was updated successfully, but these errors were encountered:
I should not break calling 3d --batch on .3d files that do not depend on each other but live in different directories. If I am not careful, then I might hit #50
Motivation
One issue described by @aseemr and @nikswamy was that the Wrapper files produced by
--batch
make all modules on the command line share the same internal state, such as counters to assign error codes to struct fields. This has the effect of having such fields of some module A appear in the Wrapper of a module B even if A and B do not depend on one another.We should not keep two distinct build processes, one for
--makefile
and another for--batch
. Eliminating the latter would make our code maintenance much easier.Proposed Solution
I believe that a solution to this problem is to make
--batch
behave closer to--makefile
, by actually making 3d call itself again on each task instead of performing internal function calls. The way I envision it is to take the tasks computed by GenMakefile and topologically sort them and execute them instead of printing them into a Makefile.Non-goal: Parallelism
I do not intend to introduce parallelism here. I believe that parallelism should be deferred to a build system. While 3d support for GNU Make can already offer parallelism, I can understand that users may want more lightweight and portable solutions. For such users, I believe that #48 will answer them, because Ninja readily and smoothly supports parallelism while being very lightweight (less than half a megabyte), so much so that I could even include it in future EverParse binary packages (by virtue of Ninja's Apache 2 open-source license.)
The text was updated successfully, but these errors were encountered: