interesting... I'll keep that in mind, Anybody against that ugly (but probably working) trick ?
On Thu, Apr 14, 2011 at 7:09 PM, Allefant <[email protected]> wrote: > On Thu, 2011-04-14 at 18:54 +0200, Allefant wrote: >> On Thu, 2011-04-14 at 18:22 +0200, David Philippi wrote: >> > Am Thursday 14 April 2011 schrieb Paul Ebermann: >> > > This does not help on the short term, but might result in this feature >> > > being implemented before Wesnoth 1.10 comes out. >> > >> > There should be a very simple workaround. Use a wrapper that sets the >> > variable >> > then does an exec of the real wesnoth binary. Might be a shell script or a >> > binary executable, whatever works best. >> > >> >> If a binary can be used, then could the real wesnoth binary exec itself >> with the modified environment (and a command-line argument preventing >> execing itself again)? >> > > Well, guess I can answer that myself: > > int main(int argc, char **argv) { > if (!getenv("OMP_WAIT_POLICY")) { > setenv("OMP_WAIT_POLICY", "PASSIVE", 1); > execv(argv[0], argv); > } > return 0; > } > > > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
