Closed Nauja closed 2 years ago
This is the expected behavior.
default_config.cmd
is there to create a default configuration while the build.bat
of the project allows to replace the parameters at will.
The advantage is multiple:
As you say, the expected behavior is that "default_config.cmd is there to create a default configuration while the build.bat of the project allows to replace the parameters at will."
But with current build.bat scripts, the default_config.cmd is not here to create a default configuration as the three build.bat override this configuration with the same exact values for "EMULATOR SETING" and "BUILD STEPS". (expect one build.bat which set an emulator variable to 1 or 0).
The change I propose is to comment with REM the variables in the build.bat that are set with exactly the same value as in default_config.cmd , allowing the user to uncomment and change the value of those variables at will, what is intended by your design.
This has the advantage of not changing the current behavior of those build.bat scripts (because they override the variables with the same values) + allowing the user to effectively change a value in default_config.cmd + allowing the user to uncomment a variable in build.bat for overriding the value from default_config.cmd .
I don't see the need for sample programs, but for the template project (which is supposed to be the basis for creating new projects) it would make sense.
Well, the need is that:
So, if you add REM to those variables it changes nothing, plus allow the user to change the default values in default_config.cmd or toggle at will the REM in build.bat.
For example in default_config.cmd you have the following variable that we are expected to change for setting the default path to emulator:
set Emulator=
REM set Emulator=%ToolsDir%\OpenMSX\openmsx.exe
REM set Emulator=%ToolsDir%\Emulicious\Emulicious.exe
REM set Emulator=%ToolsDir%\BlueMSX\blueMSX.exe
REM set Emulator=%ToolsDir%\MEISEI\meisei.exe
REM set Emulator=%ToolsDir%\fMSX\fMSX.exe
REM set Emulator=%ToolsDir%\RuMSX\MSX.exe
And in build.bat we have the following that we can toggle to override that:
::*****************************************************************************
:: TOOLS SETTINGS
::*****************************************************************************
REM set Emulator=%ToolsDir%\OpenMSX\openmsx.exe
REM set Emulator=%ToolsDir%\Emulicious\Emulicious.exe
REM set Emulator=%ToolsDir%\BlueMSX\blueMSX.exe
REM set Emulator=%ToolsDir%\MEISEI\meisei.exe
REM set Emulator=%ToolsDir%\fMSX\fMSX.exe
REM set Emulator=%ToolsDir%\RuMSX\MSX.exe
What I suggest is basically doing the same for "EMULATOR SETING" and "BUILD STEPS" which have atm the same values in default_config.cmd and built.bat
Again I don't know if in the future those variables would have different values in the build.bat and so it would make sense that they are overriden by default and that the user must change their values in the build.bat. But this suggestion is based on the fact that the build.bat set the exact same values for now.
I'm submitting a ...
What is the current behavior?
There are three .bat :
They all start with the same call to
call ..\default_config.cmd %0
for setting some default variables:However, those default variable are redefined at the end of the three
build.bat
, making the call todefault_config.cmd
useless.Changing
DoRun=1
indefault_config.cmd
has no effect because all thebuild.bat
setDoRun=0
at the end.If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
DoRun=1
indefault_config.cmd
projects/samples
build.bat s_game
What is the expected behavior?
DoRun
is set to 1 indefault_config.cmd
For this we should either add
REM
before all redefined variables or remove them in thebuild.bat
.Please tell us about your environment:
Version: 16d84fc3d55b0b4d4dd8f07ca00fedf0b12a6210 OS: Windows