Hey Jochen, Couldn't the gradle call transfer his view of the environment? I know that's a workaround but it would solve the issue, wouldn't it?
Chris On May 19, 2017 8:02:58 AM GMT+02:00, Jochen Theodorou <blackd...@gmx.org> wrote: >On 16.05.2017 19:46, Uwe Schindler wrote: >> Hi, >> >> I still don't understand why you need to change the environment >variables of the actual process. I was talking with Rémi about that >last week, and it's not obvious to me why you need that. Sure, it is >easier to change the environment of the actual process and then spawn a >child process for some non-java build tool like GCC or even another >standalone java program with option fork=true. But: Why not use the >ProcessBuilder API when spawning those childs? So you just add an >"official" build API inside Gradle (an official one, documented that >allows Gradle plugins to modify the environment variables for the >current build running). If you missed to add such an API from the >beginning (IMHO its essential for a build system like Gradle), then you >now have to tell your users: "Sorry we did something wrong and all our >(bad) hacks to allow you to change environment variables are no longer >working in the future, so please change your code. We are so sorry!" > >the daemon outlives the gradle call, and the next gradle call can be >done in a changed environment, thus the need to update the daemon. >Spawning a child process each time would be very bad for performance. > >bye Jochen -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
