2022-02-17 14:23:46 +03:00
|
|
|
@setlocal EnableDelayedExpansion EnableExtensions
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
@IF NOT DEFINED VERBOSE_MAKE @echo off
|
2019-08-29 00:18:30 +03:00
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
REM Option flags
|
|
|
|
set /a shift_counter=0
|
2020-11-28 02:14:14 +03:00
|
|
|
set /a flag_local=0
|
2019-08-29 00:18:30 +03:00
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
REM Option variables
|
2020-11-28 02:14:14 +03:00
|
|
|
set compiler=
|
|
|
|
set subcmd=
|
|
|
|
set target=build
|
2020-11-21 14:02:03 +03:00
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
set V_EXE=./v.exe
|
|
|
|
set V_BOOTSTRAP=./v_win_bootstrap.exe
|
|
|
|
set V_OLD=./v_old.exe
|
|
|
|
set V_UPDATED=./v_up.exe
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
|
2020-11-28 02:14:14 +03:00
|
|
|
REM TCC variables
|
2022-12-14 23:48:34 +03:00
|
|
|
set tcc_url=https://github.com/vlang/tccbin
|
|
|
|
set tcc_dir=thirdparty/tcc
|
|
|
|
set tcc_exe=thirdparty/tcc/tcc.exe
|
|
|
|
if "%PROCESSOR_ARCHITECTURE%" == "x86" ( set tcc_branch="thirdparty-windows-i386" ) else ( set tcc_branch="thirdparty-windows-amd64" )
|
|
|
|
if "%~1" == "-tcc32" set tcc_branch="thirdparty-windows-i386"
|
2020-11-29 18:18:49 +03:00
|
|
|
|
|
|
|
REM VC settings
|
2022-12-14 23:48:34 +03:00
|
|
|
set vc_url=https://github.com/vlang/vc
|
|
|
|
set vc_dir=%~dp0vc
|
2020-07-16 19:33:26 +03:00
|
|
|
|
2021-03-06 13:26:04 +03:00
|
|
|
REM Let a particular environment specify their own TCC and VC repos (to help mirrors)
|
2022-12-14 23:48:34 +03:00
|
|
|
if /I not ["%TCC_GIT%"] == [""] set tcc_url=%TCC_GIT%
|
|
|
|
if /I not ["%TCC_BRANCH%"] == [""] set tcc_branch=%TCC_BRANCH%
|
2020-07-16 19:33:26 +03:00
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
if /I not ["%VC_GIT%"] == [""] set vc_url=%VC_GIT%
|
2021-03-06 13:26:04 +03:00
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
pushd "%~dp0"
|
2020-07-16 19:33:26 +03:00
|
|
|
|
2020-11-21 14:02:03 +03:00
|
|
|
:verifyopt
|
2020-11-25 16:27:52 +03:00
|
|
|
REM Read stdin EOF
|
2020-11-21 14:02:03 +03:00
|
|
|
if ["%~1"] == [""] goto :init
|
2020-07-16 19:33:26 +03:00
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
REM Target options
|
|
|
|
if !shift_counter! LSS 1 (
|
|
|
|
if "%~1" == "help" (
|
2022-12-14 23:48:34 +03:00
|
|
|
if not ["%~2"] == [""] set subcmd=%~2& shift& set /a shift_counter+=1
|
2020-11-28 02:14:14 +03:00
|
|
|
)
|
2022-11-08 17:51:29 +03:00
|
|
|
for %%z in (build clean cleanall check help rebuild) do (
|
2020-11-28 02:14:14 +03:00
|
|
|
if "%~1" == "%%z" set target=%1& shift& set /a shift_counter+=1& goto :verifyopt
|
2020-11-25 16:27:52 +03:00
|
|
|
)
|
|
|
|
)
|
2020-06-04 15:07:02 +03:00
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
REM Compiler option
|
2021-02-25 14:52:12 +03:00
|
|
|
for %%g in (-gcc -msvc -tcc -tcc32 -clang) do (
|
2020-11-28 02:14:14 +03:00
|
|
|
if "%~1" == "%%g" set compiler=%~1& set compiler=!compiler:~1!& shift& set /a shift_counter+=1& goto :verifyopt
|
|
|
|
)
|
2020-11-25 16:27:52 +03:00
|
|
|
|
|
|
|
REM Standard options
|
2020-11-28 02:14:14 +03:00
|
|
|
if "%~1" == "--local" (
|
|
|
|
if !flag_local! NEQ 0 (
|
|
|
|
echo The flag %~1 has already been specified. 1>&2
|
|
|
|
exit /b 2
|
|
|
|
)
|
|
|
|
set /a flag_local=1
|
2020-11-25 16:27:52 +03:00
|
|
|
set /a shift_counter+=1
|
2020-11-21 14:02:03 +03:00
|
|
|
shift
|
|
|
|
goto :verifyopt
|
|
|
|
)
|
2020-11-28 02:14:14 +03:00
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
echo Undefined option: %~1
|
|
|
|
exit /b 2
|
2019-08-29 00:18:30 +03:00
|
|
|
|
2020-11-21 14:02:03 +03:00
|
|
|
:init
|
2020-11-28 02:14:14 +03:00
|
|
|
goto :!target!
|
|
|
|
|
2022-05-01 13:38:30 +03:00
|
|
|
:check
|
|
|
|
echo.
|
|
|
|
echo Check everything
|
2022-12-14 23:48:34 +03:00
|
|
|
"%V_EXE%" test-all
|
2022-05-01 13:38:30 +03:00
|
|
|
exit /b 0
|
|
|
|
|
2020-11-28 02:14:14 +03:00
|
|
|
:cleanall
|
|
|
|
call :clean
|
2020-11-30 10:15:52 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 exit /b %ERRORLEVEL%
|
2020-11-28 02:14:14 +03:00
|
|
|
echo.
|
|
|
|
echo Cleanup vc
|
|
|
|
echo ^> Purge TCC binaries
|
2021-09-28 13:00:27 +03:00
|
|
|
rmdir /s /q "%tcc_dir%"
|
2020-11-28 02:14:14 +03:00
|
|
|
echo ^> Purge vc repository
|
2021-09-28 13:00:27 +03:00
|
|
|
rmdir /s /q "%vc_dir%"
|
2020-11-28 02:14:14 +03:00
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:clean
|
|
|
|
echo Cleanup build artifacts
|
|
|
|
echo ^> Purge debug symbols
|
2021-09-28 13:00:27 +03:00
|
|
|
del *.pdb *.lib *.bak *.out *.ilk *.exp *.obj *.o *.a *.so
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Delete old V executable(s)
|
|
|
|
del v*.exe
|
2020-11-28 02:14:14 +03:00
|
|
|
exit /b 0
|
|
|
|
|
2022-11-08 17:51:29 +03:00
|
|
|
:rebuild
|
|
|
|
call :cleanall
|
|
|
|
goto :build
|
|
|
|
|
2020-11-28 02:14:14 +03:00
|
|
|
:help
|
|
|
|
if [!subcmd!] == [] (
|
2021-07-19 09:09:15 +03:00
|
|
|
call :usage
|
2020-11-28 02:14:14 +03:00
|
|
|
) else (
|
2021-07-19 09:09:15 +03:00
|
|
|
call :help_!subcmd!
|
2020-11-28 02:14:14 +03:00
|
|
|
)
|
|
|
|
if %ERRORLEVEL% NEQ 0 echo Invalid subcommand: !subcmd!
|
|
|
|
exit /b %ERRORLEVEL%
|
2020-11-25 16:27:52 +03:00
|
|
|
|
|
|
|
:build
|
2020-11-28 02:14:14 +03:00
|
|
|
if !flag_local! NEQ 1 (
|
2020-12-11 20:24:57 +03:00
|
|
|
call :download_tcc
|
|
|
|
if %ERRORLEVEL% NEQ 0 goto :error
|
2021-07-19 09:09:15 +03:00
|
|
|
pushd "%vc_dir%" && (
|
2020-11-21 14:02:03 +03:00
|
|
|
echo Updating vc...
|
2020-11-25 16:27:52 +03:00
|
|
|
echo ^> Sync with remote !vc_url!
|
2022-12-14 23:48:34 +03:00
|
|
|
cd %vc_dir%
|
2021-09-28 13:00:27 +03:00
|
|
|
git pull --quiet
|
|
|
|
cd ..
|
2020-11-30 10:15:52 +03:00
|
|
|
popd
|
2021-04-04 17:05:06 +03:00
|
|
|
) || call :cloning_vc
|
2020-11-28 02:14:14 +03:00
|
|
|
echo.
|
2020-11-21 14:02:03 +03:00
|
|
|
)
|
2019-08-30 00:13:53 +03:00
|
|
|
|
2020-11-21 14:02:03 +03:00
|
|
|
echo Building V...
|
2020-11-28 02:14:14 +03:00
|
|
|
if not [!compiler!] == [] goto :!compiler!_strap
|
2020-11-21 14:02:03 +03:00
|
|
|
|
2021-03-09 01:46:37 +03:00
|
|
|
|
|
|
|
REM By default, use tcc, since we have it prebuilt:
|
|
|
|
:tcc_strap
|
|
|
|
:tcc32_strap
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Attempting to build "%V_BOOTSTRAP%" (from v_win.c) with "!tcc_exe!"
|
2022-12-14 23:48:34 +03:00
|
|
|
"!tcc_exe!" -Bthirdparty/tcc -bt10 -g -w -o "%V_BOOTSTRAP%" ./vc/v_win.c -ladvapi32
|
2021-03-09 01:46:37 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 goto :compile_error
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Compiling "%V_EXE%" with "%V_BOOTSTRAP%"
|
|
|
|
"%V_BOOTSTRAP%" -keepc -g -showcc -cc "!tcc_exe!" -cflags -Bthirdparty/tcc -o "%V_UPDATED%" cmd/v
|
2021-03-09 01:46:37 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 goto :clang_strap
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
call :move_updated_to_v
|
2021-03-09 01:46:37 +03:00
|
|
|
goto :success
|
|
|
|
|
2020-11-21 14:02:03 +03:00
|
|
|
:clang_strap
|
|
|
|
where /q clang
|
|
|
|
if %ERRORLEVEL% NEQ 0 (
|
|
|
|
echo ^> Clang not found
|
2020-11-28 02:14:14 +03:00
|
|
|
if not [!compiler!] == [] goto :error
|
2020-11-21 14:02:03 +03:00
|
|
|
goto :gcc_strap
|
|
|
|
)
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Attempting to build "%V_BOOTSTRAP%" (from v_win.c) with Clang
|
2022-12-14 23:48:34 +03:00
|
|
|
clang -std=c99 -municode -g -w -o "%V_BOOTSTRAP%" ./vc/v_win.c -ladvapi32
|
2020-11-21 14:02:03 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 (
|
2021-11-22 18:07:39 +03:00
|
|
|
echo In most cases, compile errors happen because the version of Clang installed is too old
|
2021-09-28 13:00:27 +03:00
|
|
|
clang --version
|
2020-11-21 14:02:03 +03:00
|
|
|
goto :compile_error
|
|
|
|
)
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Compiling "%V_EXE%" with "%V_BOOTSTRAP%"
|
|
|
|
"%V_BOOTSTRAP%" -keepc -g -showcc -cc clang -o "%V_UPDATED%" cmd/v
|
2020-11-21 14:02:03 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 goto :compile_error
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
call :move_updated_to_v
|
2020-11-21 14:02:03 +03:00
|
|
|
goto :success
|
2019-08-30 00:13:53 +03:00
|
|
|
|
2020-11-21 14:02:03 +03:00
|
|
|
:gcc_strap
|
2020-06-19 13:54:56 +03:00
|
|
|
where /q gcc
|
|
|
|
if %ERRORLEVEL% NEQ 0 (
|
|
|
|
echo ^> GCC not found
|
2020-11-28 02:14:14 +03:00
|
|
|
if not [!compiler!] == [] goto :error
|
2020-03-18 20:15:33 +03:00
|
|
|
goto :msvc_strap
|
2019-08-30 00:13:53 +03:00
|
|
|
)
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Attempting to build "%V_BOOTSTRAP%" (from v_win.c) with GCC
|
2022-12-14 23:48:34 +03:00
|
|
|
gcc -std=c99 -municode -g -w -o "%V_BOOTSTRAP%" ./vc/v_win.c -ladvapi32
|
2020-07-10 22:50:29 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 (
|
2021-11-22 18:07:39 +03:00
|
|
|
echo In most cases, compile errors happen because the version of GCC installed is too old
|
2021-09-28 13:00:27 +03:00
|
|
|
gcc --version
|
2020-07-10 22:50:29 +03:00
|
|
|
goto :compile_error
|
|
|
|
)
|
2019-08-30 00:13:53 +03:00
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Compiling "%V_EXE%" with "%V_BOOTSTRAP%"
|
|
|
|
"%V_BOOTSTRAP%" -keepc -g -showcc -cc gcc -o "%V_UPDATED%" cmd/v
|
2020-06-19 13:54:56 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 goto :compile_error
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
call :move_updated_to_v
|
2019-08-30 00:13:53 +03:00
|
|
|
goto :success
|
|
|
|
|
2020-03-18 20:15:33 +03:00
|
|
|
:msvc_strap
|
2019-10-16 02:54:35 +03:00
|
|
|
set VsWhereDir=%ProgramFiles(x86)%
|
|
|
|
set HostArch=x64
|
|
|
|
if "%PROCESSOR_ARCHITECTURE%" == "x86" (
|
2020-03-18 20:15:33 +03:00
|
|
|
echo Using x86 Build Tools...
|
|
|
|
set VsWhereDir=%ProgramFiles%
|
|
|
|
set HostArch=x86
|
2019-10-16 02:54:35 +03:00
|
|
|
)
|
2020-06-19 13:54:56 +03:00
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
if not exist "%VsWhereDir%/Microsoft Visual Studio/Installer/vswhere.exe" (
|
2020-06-19 13:54:56 +03:00
|
|
|
echo ^> MSVC not found
|
2020-11-28 02:14:14 +03:00
|
|
|
if not [!compiler!] == [] goto :error
|
2021-03-09 01:46:37 +03:00
|
|
|
goto :compile_error
|
2020-06-19 13:54:56 +03:00
|
|
|
)
|
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
for /f "usebackq tokens=*" %%i in (`"%VsWhereDir%/Microsoft Visual Studio/Installer/vswhere.exe" -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath`) do (
|
2020-03-18 20:15:33 +03:00
|
|
|
set InstallDir=%%i
|
2019-08-29 00:38:09 +03:00
|
|
|
)
|
2019-08-29 00:18:30 +03:00
|
|
|
|
2022-12-14 23:48:34 +03:00
|
|
|
if exist "%InstallDir%/Common7/Tools/vsdevcmd.bat" (
|
|
|
|
call "%InstallDir%/Common7/Tools/vsdevcmd.bat" -arch=%HostArch% -host_arch=%HostArch% -no_logo
|
|
|
|
) else if exist "%VsWhereDir%/Microsoft Visual Studio 14.0/Common7/Tools/vsdevcmd.bat" (
|
|
|
|
call "%VsWhereDir%/Microsoft Visual Studio 14.0/Common7/Tools/vsdevcmd.bat" -arch=%HostArch% -host_arch=%HostArch% -no_logo
|
2019-08-30 00:13:53 +03:00
|
|
|
)
|
|
|
|
|
2019-12-22 22:59:51 +03:00
|
|
|
set ObjFile=.v.c.obj
|
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Attempting to build "%V_BOOTSTRAP%" (from v_win.c) with MSVC
|
2022-12-14 23:48:34 +03:00
|
|
|
cl.exe /volatile:ms /Fo%ObjFile% /W0 /MD /D_VBOOTSTRAP "vc/v_win.c" user32.lib kernel32.lib advapi32.lib shell32.lib /link /nologo /out:"%V_BOOTSTRAP%" /incremental:no
|
2020-11-30 10:15:52 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 (
|
2021-11-22 18:07:39 +03:00
|
|
|
echo In some cases, compile errors happen because of the MSVC compiler version
|
2021-09-28 13:00:27 +03:00
|
|
|
cl.exe
|
2020-11-30 10:15:52 +03:00
|
|
|
goto :compile_error
|
|
|
|
)
|
2019-08-30 00:13:53 +03:00
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo ^> Compiling "%V_EXE%" with "%V_BOOTSTRAP%"
|
|
|
|
"%V_BOOTSTRAP%" -keepc -g -showcc -cc msvc -o "%V_UPDATED%" cmd/v
|
2021-09-28 13:00:27 +03:00
|
|
|
del %ObjFile%
|
2020-06-19 13:54:56 +03:00
|
|
|
if %ERRORLEVEL% NEQ 0 goto :compile_error
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
call :move_updated_to_v
|
2020-06-19 13:54:56 +03:00
|
|
|
goto :success
|
|
|
|
|
2020-11-30 10:15:52 +03:00
|
|
|
:download_tcc
|
2022-12-14 23:48:34 +03:00
|
|
|
pushd "%tcc_dir%" && (
|
2020-11-30 10:15:52 +03:00
|
|
|
echo Updating TCC
|
|
|
|
echo ^> Syncing TCC from !tcc_url!
|
2021-09-28 13:00:27 +03:00
|
|
|
git pull --quiet
|
2020-11-30 10:15:52 +03:00
|
|
|
popd
|
2021-04-04 17:05:06 +03:00
|
|
|
) || call :bootstrap_tcc
|
|
|
|
|
2020-11-30 10:15:52 +03:00
|
|
|
if [!tcc_exe!] == [] echo ^> TCC not found, even after cloning& goto :error
|
|
|
|
echo.
|
|
|
|
exit /b 0
|
|
|
|
|
2020-03-18 20:15:33 +03:00
|
|
|
:compile_error
|
2020-07-10 22:50:29 +03:00
|
|
|
echo.
|
2021-09-28 13:00:27 +03:00
|
|
|
echo Backend compiler error
|
2019-08-30 00:13:53 +03:00
|
|
|
goto :error
|
|
|
|
|
|
|
|
:error
|
2020-06-19 13:54:56 +03:00
|
|
|
echo.
|
2019-08-30 00:13:53 +03:00
|
|
|
echo Exiting from error
|
2021-03-09 20:05:43 +03:00
|
|
|
echo ERROR: please follow the instructions in https://github.com/vlang/v/wiki/Installing-a-C-compiler-on-Windows
|
2019-08-30 00:13:53 +03:00
|
|
|
exit /b 1
|
|
|
|
|
|
|
|
:success
|
2022-12-14 23:48:34 +03:00
|
|
|
"%V_EXE%" run cmd/tools/detect_tcc.v
|
2020-06-19 13:54:56 +03:00
|
|
|
echo ^> V built successfully!
|
2022-12-14 23:48:34 +03:00
|
|
|
echo ^> To add V to your PATH, run `%V_EXE% symlink`.
|
2020-11-21 14:02:03 +03:00
|
|
|
|
2020-06-19 13:54:56 +03:00
|
|
|
:version
|
|
|
|
echo.
|
|
|
|
echo | set /p="V version: "
|
2022-12-14 23:48:34 +03:00
|
|
|
"%V_EXE%" version
|
2020-11-25 16:27:52 +03:00
|
|
|
goto :eof
|
2020-11-21 14:02:03 +03:00
|
|
|
|
|
|
|
:usage
|
|
|
|
echo Usage:
|
2020-11-25 16:27:52 +03:00
|
|
|
echo make.bat [target] [compiler] [options]
|
2020-11-21 14:02:03 +03:00
|
|
|
echo.
|
2020-11-25 16:27:52 +03:00
|
|
|
echo Compiler:
|
2021-02-25 14:52:12 +03:00
|
|
|
echo -msvc ^| -gcc ^| -tcc ^| -tcc32 ^| -clang Set C compiler
|
2020-11-21 14:02:03 +03:00
|
|
|
echo.
|
2020-11-25 16:27:52 +03:00
|
|
|
echo Target:
|
2022-05-01 13:38:30 +03:00
|
|
|
echo build[default] Compiles V using the given C compiler
|
|
|
|
echo clean Clean build artifacts and debugging symbols
|
|
|
|
echo cleanall Cleanup entire ALL build artifacts and vc repository
|
|
|
|
echo check Check that tests pass, and the repository is in a good shape for Pull Requests
|
|
|
|
echo help Display help for the given target
|
2022-11-08 17:51:29 +03:00
|
|
|
echo rebuild Fully clean/reset repository and rebuild V
|
2020-11-21 14:02:03 +03:00
|
|
|
echo.
|
|
|
|
echo Examples:
|
|
|
|
echo make.bat -msvc
|
2021-09-28 13:00:27 +03:00
|
|
|
echo make.bat -gcc --local
|
2021-02-25 14:52:12 +03:00
|
|
|
echo make.bat build -tcc --local
|
|
|
|
echo make.bat -tcc32
|
2020-11-25 16:27:52 +03:00
|
|
|
echo make.bat help clean
|
|
|
|
echo.
|
|
|
|
echo Use "make help <target>" for more information about a target, for instance: "make help clean"
|
|
|
|
echo.
|
2020-11-28 02:14:14 +03:00
|
|
|
echo Note: Any undefined/unsupported options will be ignored
|
2020-11-25 16:27:52 +03:00
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:help_help
|
|
|
|
echo Usage:
|
|
|
|
echo make.bat help [target]
|
2020-11-21 14:02:03 +03:00
|
|
|
echo.
|
2020-11-25 16:27:52 +03:00
|
|
|
echo Target:
|
2021-07-31 16:33:24 +03:00
|
|
|
echo build ^| clean ^| cleanall ^| help Query given target
|
2020-11-21 14:02:03 +03:00
|
|
|
exit /b 0
|
2020-11-25 16:27:52 +03:00
|
|
|
|
|
|
|
:help_clean
|
|
|
|
echo Usage:
|
|
|
|
echo make.bat clean
|
|
|
|
echo.
|
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:help_cleanall
|
|
|
|
echo Usage:
|
2021-07-31 16:33:24 +03:00
|
|
|
echo make.bat cleanall
|
2020-11-25 16:27:52 +03:00
|
|
|
echo.
|
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:help_build
|
|
|
|
echo Usage:
|
|
|
|
echo make.bat build [compiler] [options]
|
|
|
|
echo.
|
2022-11-08 17:51:29 +03:00
|
|
|
echo Compiler:
|
|
|
|
echo -msvc ^| -gcc ^| -tcc ^| -tcc32 ^| -clang Set C compiler
|
|
|
|
echo.
|
|
|
|
echo Options:
|
|
|
|
echo --local Use the local vc repository without
|
|
|
|
echo syncing with remote
|
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:help_rebuild
|
|
|
|
echo Usage:
|
|
|
|
echo make.bat rebuild [compiler] [options]
|
|
|
|
echo.
|
2020-11-25 16:27:52 +03:00
|
|
|
echo Compiler:
|
2021-02-25 14:52:12 +03:00
|
|
|
echo -msvc ^| -gcc ^| -tcc ^| -tcc32 ^| -clang Set C compiler
|
2020-11-25 16:27:52 +03:00
|
|
|
echo.
|
|
|
|
echo Options:
|
2022-05-01 13:38:30 +03:00
|
|
|
echo --local Use the local vc repository without
|
|
|
|
echo syncing with remote
|
2020-11-25 16:27:52 +03:00
|
|
|
exit /b 0
|
|
|
|
|
2021-04-04 17:05:06 +03:00
|
|
|
:bootstrap_tcc
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
echo Bootstrapping TCC...
|
2021-04-04 17:05:06 +03:00
|
|
|
echo ^> TCC not found
|
2021-11-22 17:24:56 +03:00
|
|
|
if "!tcc_branch!" == "thirdparty-windows-i386" ( echo ^> Downloading TCC32 from !tcc_url! , branch !tcc_branch! ) else ( echo ^> Downloading TCC64 from !tcc_url! , branch !tcc_branch! )
|
2021-09-28 13:00:27 +03:00
|
|
|
git clone --depth 1 --quiet --single-branch --branch !tcc_branch! !tcc_url! "%tcc_dir%"
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
git --no-pager -C "%tcc_dir%" log -n3
|
2021-04-04 17:05:06 +03:00
|
|
|
exit /b 0
|
|
|
|
|
|
|
|
:cloning_vc
|
|
|
|
echo Cloning vc...
|
|
|
|
echo ^> Cloning from remote !vc_url!
|
2022-01-23 13:50:19 +03:00
|
|
|
git clone --depth 1 --quiet "%vc_url%"
|
2021-04-04 17:05:06 +03:00
|
|
|
exit /b 0
|
|
|
|
|
2020-11-25 16:27:52 +03:00
|
|
|
:eof
|
|
|
|
popd
|
|
|
|
endlocal
|
2020-11-29 18:18:49 +03:00
|
|
|
exit /b 0
|
2022-08-22 22:08:28 +03:00
|
|
|
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
:move_updated_to_v
|
2022-12-14 23:48:34 +03:00
|
|
|
@REM del "%V_EXE%" &:: breaks if `make.bat` is run from `v up` b/c of held file handle on `%V_EXE%`
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
if exist "%V_EXE%" move "%V_EXE%" "%V_OLD%" >nul
|
2022-08-22 22:08:28 +03:00
|
|
|
REM sleep for at most 100ms
|
|
|
|
ping 192.0.2.1 -n 1 -w 100 >nul
|
make.bat: fix use of `make.bat` from `v up` (#16348)
* .editorconfig: fix EOL for BAT files
* make.bat: fix use of `make.bat` from `v up`
- use move semantics, instead of replace, for `v` executable updates
- fixes [#16184](https://github.com/vlang/v/issues/16184)
# [why]
`v up` updates the executable by directly calling `make.bat`, awaiting
the result, which keeps an open file handle to it's own executable file.
`make.bat` compiles and, crucially, attempts to directly replace that
`v` executable. But, in WinOS, files with open file handles cannot be
deleted/replaced, so the `make` then fails. The other key point is that,
although WinOS files with open file handles can't be deleted/replaced,
they _can be moved/renamed_.
Thus, the technique that most self-updating WinOS executables use is to
move the current executable to some alternate name (ie, *v_old.exe*) and
then move the newly updated executable to the original location (ie,
*v.exe*). The next invocation of the "original" executable will then run
the updated version.
Note, this technique also works correctly for direct invocations of `make.bat`.
2022-11-07 09:48:08 +03:00
|
|
|
move "%V_UPDATED%" "%V_EXE%" >nul
|
2022-08-22 22:08:28 +03:00
|
|
|
exit /b 0
|