<div dir="ltr"><div>Hi Eliot,</div><div><br></div><div>RE <span style="line-height:1.5">sqSCCSVersion.h:</span></div><div><span style="line-height:1.5">I'm not sure if you like this approach, but I decided to just use macros for version, date and url [1].</span></div><div><span style="line-height:1.5">I then defined those macros in a global build file [2] and added what I called $</span>COGVOPTS<span style="line-height:1.5"> to </span><span style="line-height:1.5">CFLAGS [3].</span></div><div>It looks like pharo-vm is doing something similar [4], but their approach doesn't require as much code to</div><div>change. It's probably good if Esteban explains why "he thinks it is not enough".</div><div><br></div><div><span style="line-height:1.5">Best,</span><br></div><div>Fabio</div><div><br></div><br><div class="GmSign">[1] <a href="https://github.com/fniephaus/squeak/blob/Cog/platforms/Cross/vm/sqSCCSVersion.h#L68-L86">https://github.com/fniephaus/squeak/blob/Cog/platforms/Cross/vm/sqSCCSVersion.h#L68-L86</a></div><div class="GmSign">[2] <a href="https://github.com/fniephaus/squeak/blob/Cog/.travis_build.sh#L8-L11">https://github.com/fniephaus/squeak/blob/Cog/.travis_build.sh#L8-L11</a><br></div><div class="GmSign">[3] <a href="https://github.com/fniephaus/squeak/blob/ae1a8fd6f99d0e03c37d4037c1586870ca6ff3a0/build.macos32x86/common/Makefile.vm#L107">https://github.com/fniephaus/squeak/blob/ae1a8fd6f99d0e03c37d4037c1586870ca6ff3a0/build.macos32x86/common/Makefile.vm#L107</a></div><div class="GmSign">[4] <a href="https://github.com/pharo-project/pharo-vm/blob/09a717119732559b43a13e8c6f5c43a16bba18a3/scripts/extract-commit-info.sh">https://github.com/pharo-project/pharo-vm/blob/09a717119732559b43a13e8c6f5c43a16bba18a3/scripts/extract-commit-info.sh</a></div><div class="GmSign"><br></div><div class="GmSign">-- <br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 23, 2016 at 7:55 PM Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 23.04.2016, at 19:44, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
><br>
> Hi Tobias,<br>
><br>
>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>><br>
>><br>
>>> On 23.04.2016, at 19:21, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Fabio,<br>
>>><br>
>>> and the "if not, why not?" question is a request for information, not an expression of annoyance. Subversion tags update the source in checkin. I remember Igor saying that he couldn't find out how to make gig do the same with version numbers (forgive me if my recollection is incorrect). But if git doesn't support this then we need to invent some scheme that does work, for example doing two commits, one to generate a hash and another to commit a tag. But we need sensible increment isn't version numbers, not stupid hashes. It has to be a requirement that one can tell from the output of<br>
>>> myvm -version<br>
>>> yourvm -version<br>
>>> whether the VMs are built from the same or different versions of the source and which one is more up-to-date, and that this depends on version number, not irrelevancies such as build date.<br>
>><br>
>> I did such stuff like 4 years ago for self (don't ask why)<br>
>> I changed their whole VM build process to CMake.<br>
>><br>
>> Here's some parts that vaguely do what you want want:<br>
>><br>
>> This uses "date" to generate a vm build date (lines 12 and following)<br>
>> and "git" to extract VCS infos (lines 39 and following)<br>
>> <a href="https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cmake.in" rel="noreferrer" target="_blank">https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cmake.in</a><br>
>> (it is namend .in because it gets configured itself from elsewhere)<br>
>><br>
>> It is clearly possible to switch all the stuff to git and cmake and I'd like to see that happen.<br>
>> I would love to have time for that (although it regularly makes me angry :D).<br>
>><br>
>> Best regards<br>
>> -Tobias<br>
>><br>
>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with<br>
>> probably some mix of the self vm stuff. It can really work. And it can also help us<br>
>> getting things compiled on MS compilers, btw.<br>
><br>
> What do you mean by "Ian's way" exactly? Please describe it.<br>
><br>
> Things I know:<br>
> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with<br>
<br>
Ian's unix conf uses CMake for a while now.<br>
There's no autoconf.<br>
Thers no platforms/unix/conf, neither in<br>
<a href="http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/" rel="noreferrer" target="_blank">http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/</a><br>
nor in<br>
<a href="https://github.com/fniephaus/squeak/tree/master/platforms/unix" rel="noreferrer" target="_blank">https://github.com/fniephaus/squeak/tree/master/platforms/unix</a><br>
<br>
<br>
So I'm a bit confused about what you refer to.<br>
<br>
> - gmake files work with MS compilers too<br>
><br>
> I am strongly in favor of gmake files. It's /much/ easier to work with.<br>
<br>
Sorry, i beg to differ.<br>
<br>
> Please, please, please let's limit the use of cmake to generating a config file as I've already discussed.<br>
<br>
you mean gnu make?<br>
<br>
:/<br>
<br>
However, its saturday evening, I don't like to argue at that time.<br>
Maybe I'll find some time next week to make a write up :)<br>
<br>
Best<br>
-Tobias<br>
<br>
<br>
><br>
>><br>
>><br>
>>><br>
>>> _,,,^..^,,,_ (phone)<br>
>>><br>
>>>> On Apr 23, 2016, at 9:54 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi Fabio,<br>
>>>><br>
>>>><br>
>>>>> On Apr 23, 2016, at 9:40 AM, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi all,<br>
>>>>><br>
>>>>> Bert already mentioned that I've been working on migrating the repository from SVN to Git.<br>
>>>>> I believe there are three problems that need to be solved here:<br>
>>>>><br>
>>>>> 1. Migrating SVN externals for sharing code between branches<br>
>>>>> This is currently used to share a few directories (e.g. platforms/Cross/plugins) across different<br>
>>>>> branches. But Git does no support this kind of code sharing. Instead, it supports submodules [1]<br>
>>>>> and subtrees [2]. I would suggest to move code that we want to share into separate Git<br>
>>>>> repositories and include them as submodules. I think submodules are easier to understand<br>
>>>>> (GitHub integrates them nicely in their UI). The only drawback: if someone updates code in a<br>
>>>>> shared repository, one needs to update all references to this repository as well. But I'd say this<br>
>>>>> is also a good thing: if someone changes e.g. a plugin and the change is compatible to Cog,<br>
>>>>> but incompatible to the interpreter vm, then the interpreter branch is not automatically broken<br>
>>>>> as soon as one pushes the plugin change. If the above is unclear, I'm happy to explain<br>
>>>>> submodules in more detail.<br>
>>>>><br>
>>>>> 2. Versioning and new releases<br>
>>>>> If we migrate to Git, I'd recommend to deprecate the way we do versioning in SVN. Instead, we<br>
>>>>> should use Git commit hashes and Git tags.<br>
>>>><br>
>>>> But have you modified platforms/Cross/vm/sqSCCSVersion.h to capture this information? If so, can you please send me the code so I can integrate it? If not, why not?<br>
>>>><br>
>>>>> Let's say we want to release a new version, we tag<br>
>>>>> the commit of interest with e.g. v1.0.0. When building the Cog VM on this tag, the version will be<br>
>>>>> v1.0.0. If we use GitHub, we might as well use a CI service such as Travis CI [3] to automate the<br>
>>>>> build process. That means, each time someone pushes changes to GitHub, Travis CI will build a<br>
>>>>> new Cog VM (we can call this "bleeding edge"). Let's say I push changes right after the release<br>
>>>>> of v1.0.0, the version for the next build will be something like v1.0.0-37553a9 with "37553a9"<br>
>>>>> being the short SHA1 identifying my latest commit. If we want to release e.g. v1.1.0, we just tag<br>
>>>>> a newer commit and GitHub/Travis CI does the rest for us. I already have this working, you can<br>
>>>>> find a Travis build at [4] and the result at [5]. Obviously, we can push the binaries to a different<br>
>>>>> server.<br>
>>>>><br>
>>>>> 3. Keeping a copy of the code<br>
>>>>> We of course want to keep a copy of our code at all times in case something happens with<br>
>>>>> GitHub. There are already tools that we can use to automate this. However, I wouldn't try to keep<br>
>>>>> the old SVN repository in sync. I believe this might be quite difficult and I don't see a reason to<br>
>>>>> maintain something we want to deprecate in the first place. Anyway, it should be fairly easy to<br>
>>>>> set up a tool that creates a backup on one of our servers whenever we change code on GitHub.<br>
>>>>><br>
>>>>><br>
>>>>> Doing a migration from SVN to Git(Hub) takes a few hours and I'd recommend we stop pushing<br>
>>>>> code to the SVN as soon as we start to migrate. This obviously requires everyone working with<br>
>>>>> the code base to switch to Git. So please let me know if everyone is comfortable with the<br>
>>>>> migration. If we want to do this next week, I'd recommend to do it on a Thursday or a Friday,<br>
>>>>> because I would be able to do it with Bert sitting two rooms next to me :)<br>
>>>><br>
>>>> I'm not happy to migrate until there's a functional subversion bridge that works and doesn't break my builds. Cadence pays for my time (and hence pays for a lot of the VM development we enjoy) and its builds use Jenkins and subversion and I will not cooperate with any effort that sabotages this. "Next Thursday" doesn't appear to appreciate the constraints. This has to be done carefully or I will not cooperate.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>> I hope I have thought about the important things and I'm happy to answer any questions you<br>
>>>>> might have.<br>
>>>>><br>
>>>>> Best,<br>
>>>>> Fabio<br>
>>>>><br>
>>>>> [1] <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules" rel="noreferrer" target="_blank">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a><br>
>>>>> [2] <a href="http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/" rel="noreferrer" target="_blank">http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/</a><br>
>>>>> [3] <a href="http://travis-ci.org" rel="noreferrer" target="_blank">http://travis-ci.org</a><br>
>>>>> [4] <a href="https://travis-ci.org/fniephaus/squeak/builds/119507180" rel="noreferrer" target="_blank">https://travis-ci.org/fniephaus/squeak/builds/119507180</a><br>
>>>>> [5] <a href="https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/" rel="noreferrer" target="_blank">https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>><br>
>>>>> On Sat, Apr 23, 2016 at 5:10 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
>>>>><br>
>>>>> On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:<br>
>>>>><br>
>>>>> I have to admit that I did not even know that an active git svn bridge<br>
>>>>> was possible. It sounds like this it might be very helpful.<br>
>>>>><br>
>>>>> It would be great to have the advantages of git for development, and<br>
>>>>> it could also be helpful to be able to have the <a href="http://squeakvm.org" rel="noreferrer" target="_blank">squeakvm.org</a> repo updated<br>
>>>>> periodically from git. There are portions of the platforms tree that Eliot<br>
>>>>> has been able to make identical for oscog and trunk, and this seems like<br>
>>>>> a worthwhile effort to continue.<br>
>>>>><br>
>>>>> Another possible advantage is that Ian's cmake build process takes advantage<br>
>>>>> of the SVN revision numbering, and it would be good to make sure this stays<br>
>>>>> healthy as development proceeds (it's a lot nicer than autotools).<br>
>>>>><br>
>>>>> Eliot, do you have a view on this?<br>
>>>>><br>
>>>>> Dave<br>
>>>><br>
>>>> _,,,^..^,,,_ (phone)<br>
<br>
<br>
</blockquote></div></div>