Bill McCarthy wrote:
> On Sat 29-Apr-06 3:49pm -0600, Bram Moolenaar wrote:
>
>> There are two setups, the Unix one and the MS-Windows one.
>>
>> If you use the Unix setup you need to do "make install". Thus
>> uses the files in the ../runtime directory that were unpacked
>> from the Unix tar archive.
>>
>> If you use the MS-Windows setup you should unpack the
>> vim70xxrt.zip file, which puts the runtime files below the src
>> directory, without a runtime directory. Then you can use the
>> install.exe.
>
> [...]
>
> The solutions [that appear to work] involve copying the contents
> of runtime\ on top of vim70.f\ (which should produce some pretty
> ugly results when CVS is back again
> :-)
I am not sure I understand the part about things getting ugly when
CVS is back. Do you mean that when you use CVS, the location of
your local copy of the sources and location of the install are
essentially the same?
As an aside to this thread, I would recommend using SVN today even
if just to get vim sources: "installing" the client involves
expanding zip files and does not mess with the registry; the only
commands to use are checkout and update; you don't even have to
add svn to your path!
> I was hoping there was a simple way of enabling
> dosinst.c to work with the unix tree.
That would be good (unless there is something strange about
Windows that makes having a separate directory $VIM\runtime on
Windows slow down the user-experience; in which case I wouldn't
mind the "extra" step of moving things up from inside runtime;
there is a dos-batch file below that updates the local copy of the
vim sources, builds gvim and vim, and deploys the result with
stuff below runtime moved one level up).
> Since Alpha and Beta versions have worked just fine without
> installing, and there are no patches to apply to the older vim7
> files that are are available, I'll just not "install" until the
> release and subsequent patch releases.
Given that you mentioned CVS above, I don't understand the part
about patches. My understanding is that if one uses CVS (or SVN)
to get the source, one will not have to apply patches. So even
after vim7 is released and there are several post-release patches
available, won't CVS (and SVN) reflect the latest sources without
the need to apply patches?
--Suresh
PS: The following dos batch file ran successfully yesterday.
It updates the local copy of the vim sources, builds gvim and
vim, and deploys the result with stuff below runtime moved one
level up. Before running it again, I need to address the part
about the action of the file over-writing the existing deployed
vim70f directory without saving the previous version.
@echo off
time /t
:start_here
if %USERNAME% == sgovindachar goto done_init
@echo doing init ...
set USERNAME=sgovindachar
set USERDOMAIN=yahoo
set path=%path%;c:\opt\MinGW\bin
:done_init
@echo after done_init
@echo Proceding assuming init has been done ...
@echo updating the vim sources ...
c:\opt\svn\svn-win32-1.3.1\bin\svn.exe up vim7
pushd c:\home\suresh\develop\vim\vim7\src
mingw32-make.exe -f Make_ming.mak clean
mingw32-make.exe -f Make_ming.mak FEATURES=HUGE DEBUG=no GUI=yes OLE=yes
PERL=C:/opt/perl PERL_VER=58 ARCH=pentium4 CPUNR=pentium4 CC="gcc -msse
-mfpmath=sse -mmmx" OPTIMIZE=MAXSPEED
move /y *.exe ..
mingw32-make.exe -f Make_ming.mak clean
mingw32-make.exe -f Make_ming.mak FEATURES=HUGE DEBUG=no GUI=no OLE=yes
PERL=C:/opt/perl PERL_VER=58 ARCH=pentium4 CPUNR=pentium4 CC="gcc -msse
-mfpmath=sse -mmmx" OPTIMIZE=MAXSPEED
move /y vim.exe ..
cd ..
xcopy /q /i * c:\opt\vim\vim70f
cd runtime
xcopy /e /q /i * c:\opt\vim\vim70f
popd
:all_done
@time /t
@echo alldone
