2022-02-17 13:23:46 +02: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 00:48:08 -06:00
@ IF NOT DEFINED VERBOSE_MAKE @ echo off
2019-08-29 00:18:30 +03:00
2020-11-25 08:27:52 -05:00
REM Option flags
set /a shift_counter = 0
2020-11-27 18:14:14 -05:00
set /a flag_local = 0
2019-08-29 00:18:30 +03:00
2020-11-25 08:27:52 -05:00
REM Option variables
2020-11-27 18:14:14 -05:00
set compiler =
set subcmd =
set target = build
2020-11-21 06:02:03 -05:00
2022-12-14 15:48:34 -05: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
2026-03-27 13:32:51 +02:00
set V_C_FILE = ./vc/v_win.c
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 00:48:08 -06:00
2020-11-27 18:14:14 -05:00
REM TCC variables
2022-12-14 15:48:34 -05:00
set tcc_url = https://github.com/vlang/tccbin
2026-03-13 09:58:30 +03:00
set tcc_dir = %~dp0 thirdparty\tcc
set tcc_exe = %tcc_dir% \tcc.exe
2022-12-14 15:48:34 -05:00
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 17:18:49 +02:00
REM VC settings
2022-12-14 15:48:34 -05:00
set vc_url = https://github.com/vlang/vc
set vc_dir = %~dp0 vc
2020-07-16 09:33:26 -07:00
2021-03-06 12:26:04 +02:00
REM Let a particular environment specify their own TCC and VC repos (to help mirrors)
2022-12-14 15:48:34 -05:00
if /I not [" %TCC_GIT% " ] == [" " ] set tcc_url = %TCC_GIT%
if /I not [" %TCC_BRANCH% " ] == [" " ] set tcc_branch = %TCC_BRANCH%
2020-07-16 09:33:26 -07:00
2022-12-14 15:48:34 -05:00
if /I not [" %VC_GIT% " ] == [" " ] set vc_url = %VC_GIT%
2021-03-06 12:26:04 +02:00
2022-12-14 15:48:34 -05:00
pushd " %~dp0 "
2020-07-16 09:33:26 -07:00
2020-11-21 06:02:03 -05:00
: verifyopt
2020-11-25 08:27:52 -05:00
REM Read stdin EOF
2020-11-21 06:02:03 -05:00
if " %~1 " ] == [" " ] goto : init
2020-07-16 09:33:26 -07:00
2020-11-25 08:27:52 -05:00
REM Target options
if !shift_counter! LSS 1 (
2023-10-22 22:52:25 +02:00
if " %~1 " == " help " (
if not [" %~2 " ] == [" " ] set subcmd = %~2 & shift & set /a shift_counter += 1
)
for %% z in ( build clean cleanall check help rebuild) do (
if " %~1 " == " %% z " set target = %1 & shift & set /a shift_counter += 1 & goto : verifyopt
)
2020-11-25 08:27:52 -05:00
)
2020-06-04 20:07:02 +08:00
2020-11-25 08:27:52 -05:00
REM Compiler option
2021-02-25 19:52:12 +08:00
for %% g in ( -gcc -msvc -tcc -tcc32 -clang) do (
2023-10-22 22:52:25 +02:00
if " %~1 " == " %% g " set compiler = %~1 & set compiler = !compiler:~1! & shift & set /a shift_counter += 1 & goto : verifyopt
2020-11-27 18:14:14 -05:00
)
2020-11-25 08:27:52 -05:00
REM Standard options
2020-11-27 18:14:14 -05:00
if " %~1 " == " --local " (
2023-10-22 22:52:25 +02:00
if !flag_local! NEQ 0 (
echo The flag %~1 has already been specified. 1 >& 2
exit /b 2
)
set /a flag_local = 1
set /a shift_counter += 1
shift
goto : verifyopt
2020-11-21 06:02:03 -05:00
)
2020-11-27 18:14:14 -05:00
2020-11-25 08:27:52 -05:00
echo Undefined option: %~1
exit /b 2
2019-08-29 00:18:30 +03:00
2020-11-21 06:02:03 -05:00
: init
2020-11-27 18:14:14 -05:00
goto : !target!
2022-05-01 13:38:30 +03:00
: check
echo .
echo Check everything
2022-12-14 15:48:34 -05:00
" %V_EXE% " test-all
2022-05-01 13:38:30 +03:00
exit /b 0
2020-11-27 18:14:14 -05:00
: cleanall
call : clean
2020-11-30 02:15:52 -05:00
if %ERRORLEVEL% NEQ 0 exit /b %ERRORLEVEL%
2020-11-27 18:14:14 -05:00
echo .
echo Cleanup vc
echo ^> Purge TCC binaries
2021-09-28 13:00:27 +03:00
rmdir /s /q " %tcc_dir% "
2020-11-27 18:14:14 -05:00
echo ^> Purge vc repository
2021-09-28 13:00:27 +03:00
rmdir /s /q " %vc_dir% "
2020-11-27 18:14:14 -05: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 00:48:08 -06:00
echo ^> Delete old V executable(s)
del v*.exe
2020-11-27 18:14:14 -05:00
exit /b 0
2022-11-08 08:51:29 -06:00
: rebuild
call : cleanall
goto : build
2020-11-27 18:14:14 -05:00
: help
if == [] (
2023-10-22 22:52:25 +02:00
call : usage
2020-11-27 18:14:14 -05:00
) else (
2023-10-22 22:52:25 +02:00
call : help_!subcmd!
2020-11-27 18:14:14 -05:00
)
if %ERRORLEVEL% NEQ 0 echo Invalid subcommand: !subcmd!
exit /b %ERRORLEVEL%
2020-11-25 08:27:52 -05:00
: build
2020-11-27 18:14:14 -05:00
if !flag_local! NEQ 1 (
2023-10-22 22:52:25 +02:00
call : download_tcc
if %ERRORLEVEL% NEQ 0 goto : error
2026-03-13 09:58:30 +03:00
if exist " %vc_dir% " (
pushd " %vc_dir% " && (
echo Updating vc...
echo ^> Sync with remote !vc_url!
cd %vc_dir%
git pull --quiet
cd ..
popd
)
) else (
call : cloning_vc
)
2023-10-22 22:52:25 +02:00
echo .
2020-11-21 06:02:03 -05:00
)
2019-08-29 22:13:53 +01:00
2020-11-21 06:02:03 -05:00
echo Building V...
2020-11-27 18:14:14 -05:00
if not [!compiler!] == [] goto : !compiler!_strap
2020-11-21 06:02:03 -05:00
2021-03-09 00:46:37 +02:00
REM By default, use tcc, since we have it prebuilt:
: tcc_strap
: tcc32_strap
2026-02-26 11:35:05 +03:00
echo ^> Attempting to build " %V_BOOTSTRAP% " (from %V_C_FILE% ) with " !tcc_exe! "
2026-04-14 00:04:28 +03:00
" !tcc_exe! " -B" %tcc_dir% " -bt10 -g -w -o " %V_BOOTSTRAP% " " %V_C_FILE% " -ladvapi32 -lws2_32 -Wl,-stack=33554432
2021-03-09 00:46:37 +02: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 00:48:08 -06:00
echo ^> Compiling " %V_EXE% " with " %V_BOOTSTRAP% "
2026-03-13 14:34:23 +03:00
REM Keep the TCC root relative here; V forwards -cflags through a response file.
REM An absolute -B path breaks there when the checkout path contains spaces.
" %V_BOOTSTRAP% " -keepc -g -showcc -cc " !tcc_exe! " -cflags -Bthirdparty/tcc -o " %V_UPDATED% " cmd/v
2021-03-09 00:46:37 +02: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 00:48:08 -06:00
call : move_updated_to_v
2021-03-09 00:46:37 +02:00
goto : success
2020-11-21 06:02:03 -05:00
: clang_strap
where /q clang
if %ERRORLEVEL% NEQ 0 (
echo ^> Clang not found
2020-11-27 18:14:14 -05:00
if not [!compiler!] == [] goto : error
2020-11-21 06:02:03 -05:00
goto : gcc_strap
)
2026-02-26 11:35:05 +03:00
echo ^> Attempting to build " %V_BOOTSTRAP% " (from %V_C_FILE% ) with Clang
2026-04-14 00:04:28 +03:00
clang -std=c99 -municode -g -w -o " %V_BOOTSTRAP% " " %V_C_FILE% " -ladvapi32 -lws2_32 -Wl,-stack=33554432
2020-11-21 06:02:03 -05:00
if %ERRORLEVEL% NEQ 0 (
2021-11-22 17:07:39 +02: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 06:02:03 -05: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 00:48:08 -06:00
echo ^> Compiling " %V_EXE% " with " %V_BOOTSTRAP% "
" %V_BOOTSTRAP% " -keepc -g -showcc -cc clang -o " %V_UPDATED% " cmd/v
2020-11-21 06:02:03 -05: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 00:48:08 -06:00
call : move_updated_to_v
2020-11-21 06:02:03 -05:00
goto : success
2019-08-29 22:13:53 +01:00
2020-11-21 06:02:03 -05:00
: gcc_strap
2020-06-19 12:54:56 +02:00
where /q gcc
if %ERRORLEVEL% NEQ 0 (
echo ^> GCC not found
2020-11-27 18:14:14 -05:00
if not [!compiler!] == [] goto : error
2020-03-19 01:15:33 +08:00
goto : msvc_strap
2019-08-29 22:13:53 +01:00
)
2026-02-26 11:35:05 +03:00
echo ^> Attempting to build " %V_BOOTSTRAP% " (from %V_C_FILE% ) with GCC
2026-04-14 00:04:28 +03:00
gcc -std=c99 -municode -g -w -o " %V_BOOTSTRAP% " " %V_C_FILE% " -ladvapi32 -lws2_32 -Wl,-stack=33554432
2020-07-10 21:50:29 +02:00
if %ERRORLEVEL% NEQ 0 (
2021-11-22 17:07:39 +02: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 21:50:29 +02:00
goto : compile_error
)
2019-08-29 22:13:53 +01: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 00:48:08 -06:00
echo ^> Compiling " %V_EXE% " with " %V_BOOTSTRAP% "
" %V_BOOTSTRAP% " -keepc -g -showcc -cc gcc -o " %V_UPDATED% " cmd/v
2020-06-19 12:54:56 +02: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 00:48:08 -06:00
call : move_updated_to_v
2019-08-29 22:13:53 +01:00
goto : success
2020-03-19 01:15:33 +08:00
: msvc_strap
2019-10-16 02:54:35 +03:00
set VsWhereDir = %ProgramFiles(x86)%
set HostArch = x64
if " %PROCESSOR_ARCHITECTURE% " == " x86 " (
2020-03-19 01:15:33 +08:00
echo Using x86 Build Tools...
set VsWhereDir = %ProgramFiles%
set HostArch = x86
2019-10-16 02:54:35 +03:00
)
2020-06-19 12:54:56 +02:00
2022-12-14 15:48:34 -05:00
if not exist " %VsWhereDir% /Microsoft Visual Studio/Installer/vswhere.exe " (
2020-06-19 12:54:56 +02:00
echo ^> MSVC not found
2020-11-27 18:14:14 -05:00
if not [!compiler!] == [] goto : error
2021-03-09 00:46:37 +02:00
goto : compile_error
2020-06-19 12:54:56 +02:00
)
2022-12-14 15:48:34 -05: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-19 01:15:33 +08:00
set InstallDir = %% i
2019-08-29 00:38:09 +03:00
)
2019-08-29 00:18:30 +03:00
2022-12-14 15:48:34 -05: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-29 22:13:53 +01:00
)
2019-12-22 22:59:51 +03:00
set ObjFile = .v.c.obj
2026-03-13 09:58:30 +03:00
if not exist " %tcc_exe% " call : download_tcc
if exist " %tcc_exe% " (
echo ^> Bootstrapping " %V_BOOTSTRAP% " from %V_C_FILE% with " !tcc_exe! " before compiling " %V_EXE% " with MSVC
2026-04-14 00:04:28 +03:00
" !tcc_exe! " -B" %tcc_dir% " -bt10 -g -w -o " %V_BOOTSTRAP% " " %V_C_FILE% " -ladvapi32 -lws2_32 -Wl,-stack=33554432
2026-03-13 09:58:30 +03:00
if %ERRORLEVEL% NEQ 0 goto : compile_error
) else (
echo ^> Attempting to build " %V_BOOTSTRAP% " from %V_C_FILE% with MSVC
cl.exe /volatile:ms /Fo%ObjFile% /W0 /MD /D_VBOOTSTRAP /F33554432 " %V_C_FILE% " user32.lib kernel32.lib advapi32.lib shell32.lib ws2_32.lib /link /nologo /out:" %V_BOOTSTRAP% " /incremental:no
if %ERRORLEVEL% NEQ 0 (
echo In some cases, compile errors happen because of the MSVC compiler version
cl.exe
if exist %ObjFile% del %ObjFile%
goto : compile_error
)
2020-11-30 02:15:52 -05:00
)
2019-08-29 22:13:53 +01: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 00:48:08 -06:00
echo ^> Compiling " %V_EXE% " with " %V_BOOTSTRAP% "
" %V_BOOTSTRAP% " -keepc -g -showcc -cc msvc -o " %V_UPDATED% " cmd/v
2026-03-13 09:58:30 +03:00
if exist %ObjFile% del %ObjFile%
2020-06-19 12:54:56 +02: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 00:48:08 -06:00
call : move_updated_to_v
2020-06-19 12:54:56 +02:00
goto : success
2020-11-30 02:15:52 -05:00
: download_tcc
2026-03-13 09:58:30 +03:00
if exist " %tcc_dir% " (
pushd " %tcc_dir% " && (
echo Updating TCC
echo ^> Syncing TCC from !tcc_url!
git pull --quiet
popd
)
) else (
call : bootstrap_tcc
)
if not exist " %tcc_exe% " echo ^> TCC not found, even after cloning& goto : error
2020-11-30 02:15:52 -05:00
echo .
exit /b 0
2020-03-19 01:15:33 +08:00
: compile_error
2020-07-10 21:50:29 +02:00
echo .
2021-09-28 13:00:27 +03:00
echo Backend compiler error
2019-08-29 22:13:53 +01:00
goto : error
: error
2020-06-19 12:54:56 +02:00
echo .
2019-08-29 22:13:53 +01:00
echo Exiting from error
2021-03-09 19:05:43 +02:00
echo ERROR: please follow the instructions in https://github.com/vlang/v/wiki/Installing-a-C-compiler-on-Windows
2019-08-29 22:13:53 +01:00
exit /b 1
: success
2022-12-14 15:48:34 -05:00
" %V_EXE% " run cmd/tools/detect_tcc.v
2020-06-19 12:54:56 +02:00
echo ^> V built successfully!
2022-12-14 15:48:34 -05:00
echo ^> To add V to your PATH, run `%V_EXE% symlink`.
2025-01-26 19:28:32 +02:00
echo ^> Note: Antivirus programs may sometimes tell you there is a virus in V (there aren't any). They can also slow compilation by a considerable amount. Consider adding exemptions for the V install directory as well as your V project folders.
2020-11-21 06:02:03 -05:00
2020-06-19 12:54:56 +02:00
: version
echo .
echo | set /p = " V version: "
2022-12-14 15:48:34 -05:00
" %V_EXE% " version
2024-11-07 20:59:19 +02:00
" %V_EXE% " run .github/problem-matchers/register_all.vsh
2020-11-25 08:27:52 -05:00
goto : eof
2020-11-21 06:02:03 -05:00
: usage
echo Usage:
2020-11-25 08:27:52 -05:00
echo make.bat [target] [compiler] [options]
2020-11-21 06:02:03 -05:00
echo .
2020-11-25 08:27:52 -05:00
echo Compiler:
2021-02-25 19:52:12 +08:00
echo -msvc ^| -gcc ^| -tcc ^| -tcc32 ^| -clang Set C compiler
2020-11-21 06:02:03 -05:00
echo .
2020-11-25 08:27:52 -05: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 08:51:29 -06:00
echo rebuild Fully clean/reset repository and rebuild V
2020-11-21 06:02:03 -05:00
echo .
echo Examples:
echo make.bat -msvc
2021-09-28 13:00:27 +03:00
echo make.bat -gcc --local
2021-02-25 19:52:12 +08:00
echo make.bat build -tcc --local
echo make.bat -tcc32
2020-11-25 08:27:52 -05: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-27 18:14:14 -05:00
echo Note: Any undefined/unsupported options will be ignored
2020-11-25 08:27:52 -05:00
exit /b 0
: help_help
echo Usage:
echo make.bat help [target]
2020-11-21 06:02:03 -05:00
echo .
2020-11-25 08:27:52 -05:00
echo Target:
2021-07-31 15:33:24 +02:00
echo build ^| clean ^| cleanall ^| help Query given target
2020-11-21 06:02:03 -05:00
exit /b 0
2020-11-25 08:27:52 -05:00
: help_clean
echo Usage:
echo make.bat clean
echo .
exit /b 0
: help_cleanall
echo Usage:
2021-07-31 15:33:24 +02:00
echo make.bat cleanall
2020-11-25 08:27:52 -05:00
echo .
exit /b 0
: help_build
echo Usage:
echo make.bat build [compiler] [options]
echo .
2022-11-08 08:51:29 -06: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 08:27:52 -05:00
echo Compiler:
2021-02-25 19:52:12 +08:00
echo -msvc ^| -gcc ^| -tcc ^| -tcc32 ^| -clang Set C compiler
2020-11-25 08:27:52 -05: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 08:27:52 -05: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 00:48:08 -06:00
echo Bootstrapping TCC...
2021-04-04 17:05:06 +03:00
echo ^> TCC not found
2021-11-22 16:24:56 +02: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! )
2023-02-02 18:33:34 +02:00
git clone --filter=blob:none --quiet --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 00:48:08 -06: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!
2023-02-02 18:33:34 +02:00
git clone --filter=blob:none --quiet " %vc_url% "
2021-04-04 17:05:06 +03:00
exit /b 0
2020-11-25 08:27:52 -05:00
: eof
popd
endlocal
2020-11-29 17:18:49 +02: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 00:48:08 -06:00
: move_updated_to_v
2022-12-14 15:48:34 -05: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 00:48:08 -06: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 00:48:08 -06:00
move " %V_UPDATED% " " %V_EXE% " > nul
2022-08-22 22:08:28 +03:00
exit /b 0
