There is a general issue with this PR, the script in util/windows/dynawo.cmd was not written to be used directly in the git repository as the dynawo.sh is for Linux. It was only meant to be paste in the install directory and used from there. When we ported dyn-algos to Windows Frederic wrote a new script that could handle both working in the git repository and the install directory. So either we need to rethink this script and its counterpart for the deploy or we need to separate the new build method in a new script.

so if my understanding is correct the latest dynawo.cmd can run a simulation independently if we are in a distrib or in a dev environment ? What happens if the user calls build in a distrib?

so if my understanding is correct the latest dynawo.cmd can run a simulation independently if we are in a distrib or in a dev environment ? What happens if the user calls build in a distrib?

Not sure about that, I would let @barondim answer. I would not modify the util\windows\dynawo.cmd to add build commands. I would create a new one just to encapsulate the cmake commands and still launch the dynawo.cmd from the install folder once copied there. There is also a dynawo.cmd that is copied in a distrib and that is independent.

so if my understanding is correct the latest dynawo.cmd can run a simulation independently if we are in a distrib or in a dev environment ? What happens if the user calls build in a distrib?

Not sure about that, I would let @barondim answer. I would not modify the util\windows\dynawo.cmd to add build commands. I would create a new one just to encapsulate the cmake commands and still launch the dynawo.cmd from the install folder once copied there. There is also a dynawo.cmd that is copied in a distrib and that is independent.

I thought it could be a good idea to modify the dynawo.cmd script like it was done for dynawo-algorithms.cmd
This way we could get a polyvalent script which can do everything : build, deploy, distrib,...
It would be coherent with dynawo-algorithms and it also would centralize everything in the same script.

so if my understanding is correct the latest dynawo.cmd can run a simulation independently if we are in a distrib or in a dev environment ? What happens if the user calls build in a distrib?

Not sure about that, I would let @barondim answer. I would not modify the util\windows\dynawo.cmd to add build commands. I would create a new one just to encapsulate the cmake commands and still launch the dynawo.cmd from the install folder once copied there. There is also a dynawo.cmd that is copied in a distrib and that is independent.

I thought it could be a good idea to modify the dynawo.cmd script like it was done for dynawo-algorithms.cmd This way we could get a polyvalent script which can do everything : build, deploy, distrib,... It would be coherent with dynawo-algorithms and it also would centralize everything in the same script.

Why not but in this case we need to go to the bottom of things. For example in the dynawo-algorithm batch file, the build command cannot be called in a distrib:

if not defined _devmode (
  echo error: 'build' command is only available in developper mode ! 1>&2
  exit /B 1
)

My issue with what has been done in dyn-algo is that we reproduce in batch the same things as we have in bash, but batch is way more painful than bash, we don't have the capacity to sustain it well and this is not the spirit on windows to have such things. At the beginning I only wanted some small cmd to handle simple things and simple env variables. We can do the full things like in dyn-algo but I was not for it in the first place and will not be for it now as it is too much work for small gain

There is a general issue with this PR, the script in util/windows/dynawo.cmd was not written to be used directly in the git repository as the dynawo.sh is for Linux. It was only meant to be paste in the install directory and used from there. When we ported dyn-algos to Windows Frederic wrote a new script that could handle both working in the git repository and the install directory. So either we need to rethink this script and its counterpart for the deploy or we need to separate the new build method in a new script.

Actually it's dynawo/sources/Launcher/dynawo.cmd.in which is pasted in the install directory. util/windows/dynawo.cmd is pasted in the deploy

There is a general issue with this PR, the script in util/windows/dynawo.cmd was not written to be used directly in the git repository as the dynawo.sh is for Linux. It was only meant to be paste in the install directory and used from there. When we ported dyn-algos to Windows Frederic wrote a new script that could handle both working in the git repository and the install directory. So either we need to rethink this script and its counterpart for the deploy or we need to separate the new build method in a new script.

Actually it's dynawo/sources/Launcher/dynawo.cmd.in which is pasted in the install directory. util/windows/dynawo.cmd is pasted in the deploy

My remark still holds, the script was written to be used once installed or deployed and not to compile like envDynawo.sh. We can change the behavior but we need to rewrite them from scratch maybe and look at what was done in dyn-algo and dfl...

There is a general issue with this PR, the script in util/windows/dynawo.cmd was not written to be used directly in the git repository as the dynawo.sh is for Linux. It was only meant to be paste in the install directory and used from there. When we ported dyn-algos to Windows Frederic wrote a new script that could handle both working in the git repository and the install directory. So either we need to rethink this script and its counterpart for the deploy or we need to separate the new build method in a new script.

Actually it's dynawo/sources/Launcher/dynawo.cmd.in which is pasted in the install directory. util/windows/dynawo.cmd is pasted in the deploy

My remark still holds, the script was written to be used once installed or deployed and not to compile like envDynawo.sh. We can change the behavior but we need to rewrite them from scratch maybe and look at what was done in dyn-algo and dfl...

Ok, I think I agree with you now. I think we should keep the current behaviour :
util/windows/dynawo.cmd is used for the deploy
dynawo/sources/Launcher/dynawo.cmd.in is used for the install

But in that case, I'm wondering if it's not overkill to create a specific cmd script just to build the project while it's already possible to build it with a few CMake commands.

If we want to create a cmd script to build the project anyway, I guess it will be quick to create since it just needs to contains the CMake commands in the README

There is a general issue with this PR, the script in util/windows/dynawo.cmd was not written to be used directly in the git repository as the dynawo.sh is for Linux. It was only meant to be paste in the install directory and used from there. When we ported dyn-algos to Windows Frederic wrote a new script that could handle both working in the git repository and the install directory. So either we need to rethink this script and its counterpart for the deploy or we need to separate the new build method in a new script.

Actually it's dynawo/sources/Launcher/dynawo.cmd.in which is pasted in the install directory. util/windows/dynawo.cmd is pasted in the deploy

My remark still holds, the script was written to be used once installed or deployed and not to compile like envDynawo.sh. We can change the behavior but we need to rewrite them from scratch maybe and look at what was done in dyn-algo and dfl...

Ok, I think I agree with you now. I think we should keep the current behaviour : util/windows/dynawo.cmd is used for the deploy dynawo/sources/Launcher/dynawo.cmd.in is used for the install

But in that case, I'm wondering if it's not overkill to create a specific cmd script just to build the project while it's already possible to build it with a few CMake commands.

If we want to create a cmd script to build the project anyway, I guess it will be quick to create since it just needs to contains the CMake commands in the README

The original ticket was only about correcting the Readme for Windows users. We can go back to simply doing that then.