Closed spacesinmotion closed 5 years ago
because it is downloaded from an external server, which does not use any version control.
this is not correct: v.c is located in https://github.com/vlang/vc
The vc
repository has versioning too: https://github.com/vlang/vc/releases
part of this Makefile
:
v.c:
curl -Os https://raw.githubusercontent.com/vlang/vc/master/v.c
${CC} -std=gnu11 -w -o v v.c -lm
it is not versionized ... you always get the newest version. It is not working. At least not for me...
git checkout HEAD^^
make
will fail almost everytime someone changes some compiler/*.v
even worse: the newest version just contains the bugs that I want to wait to be fixed!
Ok I see, thanks.
Sorry for such instability at this stage.
Is your project open sourced? Sounds like it could be a good way to test the language.
The vc repository is versioned and it is possible to download an older v.c, but it is not obvious which version an old commit of V was built with.
The two alternatives I prefer would be:
Updating the Makefile and make.bat each release or breaking change to download a specific version of v.c. Now that would probably be https://raw.githubusercontent.com/vlang/vc/0.1.17/v.c
or https://raw.githubusercontent.com/vlang/vc/9386bc1c7fbda14f4f1050d8732a31898779472e/v.c
(current master).
Or import vc as a git submodule. Possibly a bit more complicated but doesn't require updating two files.
@medvednikov No need to be sorry. I want to suggest imrovements. I'm not here complain. I would not be here in case that I did not like what you do ...
And my project is not open source, it's a playground at moment, but I can give an example of things that broke regularly.
@Rendims, @medvednikov
Maybe I overread it, but what exactly is bad about adding v.c
to this repository, except that it is big? ... It looks to me, that you make your life unnecessarily complicated.
@spacesinmotion, I just don't like generated and/or constantly changing files in code repositories.
It also messes with statistics, adding and deleting hundreds or thousands of lines when only a few lines of V changed, and would probably make GitHub think this repo is mostly C code.
But not being able to (easily) go back to a previous version is a problem. Running git bisect on old commits to find when a regression started isn't going to work unless the latest version can compile the old version or Makefile is tweaked to download the right old v.c at every step.
As long as I'm able to bootstrap my code with a download from vc repository, I do nolonger see this as an issue...
Situation
Currently I'm not able to build an old version without an old v compiler installed. This is kind of complex transitive condition to build the
v
compiler.The problem is that I might not be able to create
v.c
, because it is downloaded from an external server, which does not use any version control.I saw #510, but that solution is not working at all. The
vlang/vc
and this repository do not share any version information.Solution
If
v.c
is added to this repository I would be able to simply check out any version I want to use andmake
it. As I would expect that a continious integration/delivery should work. Yes it is a big file, but git would handle this for us. That I'm not able to build an old version is way worse, If you ask me ...Alternative solution (personally I do not like that)
the
Makefile
should load the correct version ofv.c
for every step in history of that repository that I might check out.Remarks
My
v
code depends on features that get broken every 2nd version or so ... (as long as it is not a stable version, I'm ok with that) If I find out my code does not compile, I'm currently not able to switch back to an old version, without an avoidable big effort.