Hi Tobias,
On Sat, Apr 23, 2016 at 10:55 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 23.04.2016, at 19:44, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tobias,
On Apr 23, 2016, at 10:30 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 23.04.2016, at 19:21, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Fabio,
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
myvm -version yourvm -version 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.
I did such stuff like 4 years ago for self (don't ask why) I changed their whole VM build process to CMake.
Here's some parts that vaguely do what you want want:
This uses "date" to generate a vm build date (lines 12 and following) and "git" to extract VCS infos (lines 39 and following)
https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cm...
(it is namend .in because it gets configured itself from elsewhere)
It is clearly possible to switch all the stuff to git and cmake and I'd
like to see that happen.
I would love to have time for that (although it regularly makes me
angry :D).
Best regards -Tobias
PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should
follo Ians way with
probably some mix of the self vm stuff. It can really work. And it
can also help us
getting things compiled on MS compilers, btw.
What do you mean by "Ian's way" exactly? Please describe it.
Things I know:
- 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
Ian's unix conf uses CMake for a while now. There's no autoconf. Thers no platforms/unix/conf, neither in http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/ nor in https://github.com/fniephaus/squeak/tree/master/platforms/unix
Yes, I know. I also know that, for example, http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/Plugins.cmake is /not/ easy to work with. It is essentially impenetrable without significant thought. I will critique fully below.
So I'm a bit confused about what you refer to.
- gmake files work with MS compilers too
I am strongly in favor of gmake files. It's /much/ easier to work with.
Sorry, i beg to differ.
Please, please, please let's limit the use of cmake to generating a
config file as I've already discussed.
you mean gnu make?
Yes. And as examples I invite you to read, for example,
http://www.squeakvm.org/svn/squeak/branches/Cog/ build.macos64x64/common/Makefile.app build.macos64x64/common/Makefile.app.newspeak build.macos64x64/common/Makefile.app.squeak.cog build.macos64x64/common/Makefile.flags build.macos64x64/common/Makefile.plugin build.macos64x64/common/Makefile.rules build.macos64x64/common/Makefile.vm
build.macos64x64/pharo.cog.spur/Makefile build.macos64x64/squeak.cog.spur/Makefile build.macos64x64/squeak.stack.spur/Makefile
build.win32x86/common/Makefile build.win32x86/common/Makefile.plugin build.win32x86/common/Makefile.rules
So what are the trade offs? I'll mark cmake plusses with '+', gmake advantages over cmake '-'.
+ cmake and autoconf include systems for computing a platform-specific config.h file from aplatform-independent template that identifies a platform's basic facilities, word size, available APIs, etc. This is of value. I've described earlier in this thread how I want to use this, by generating a single copy of the platform-speciifc file per platform-specific build directory, where each build directory includes several distinct VMs (squeak vs pharo vs newspeak * context vs stack vs cog vs sista * v3 vs spur) and a single copy of support libraries such as Bochs, Cairo et al.
- cmake is second-order. Editing the code does /not/ produce the end product. One must run the build system, inspect the reduced makefiles and map back to the cmake input to correct errors. This is hard. cmake is not significantly better than autoconf in this regard. It took me longer to modify the autoconf system to optionally compile the cogit.c file (now cogitIA32.c, cogitARM32.c et al) when adding Cog to the StackInterpreter build than it did to write the entire set of Mac OS X gnu make makefiles.
- cmake requires that for complex plains one both edit the cmake config files /and/ cmake Makefile includes (e.g. there are
http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/plugins/XDisplayCont... {build.cmake,config.cmake} but in the Gnu makefiles there is only ever a single Makefile that includes a more generic one.
- cmake duplicates effort for every build. The Cog sources build VMs for two versions (v3 & Spur) of two Smalltalk dialects (each with their own icon sets), and for Newspeak. To be able to debug the VM effectively each VM is bolt in three forms, production, assert (asserts at -O1) and debug (asserts at -O0). That's a /lot/ of builds, and waiting for cmake (or autoconf) to configure, and redoing it for each separate build is a waste. The gnu makefiles are first order; they are simply used directly; no slow configure step is required
- AFAICT, there is no support for /any/ build dependency information in the cmake sources (this is information on which C files include which headers, or other C files, which is essential in enabling fast builds when developing the VM). The Gnu Makefiles I've written, following well-documented established patterns, maintains dependency information and shares it between production,assert and debug builds.
- cmake offers no solution to the problem of building support libraries; neither does gnu make. But in my build layout there is a simple convention for multi-platform builds, and for sharing a single copy of each support library between all builds for that platform, i.e. http://www.squeakvm.org/svn/squeak/branches/Cog/ build.linux32ARM build.linux64x64 build.macos64x64 build.linux32x86 build.macos32x86 build.win32x86 and e.g. bochsx64 and bochsx86 within those directories.
:/
However, its saturday evening, I don't like to argue at that time. Maybe I'll find some time next week to make a write up :)
OK, but please address my points above, and please realise that my preferred approach is based on hard experience; I'm not choosing gnu makefiles because of nostalgia or familiarity. I chose them because they're much more productive, apart from cake and autoconf's one advantage, generating a platform-specific config.h. And that I'd like to steal.
Best -Tobias
_,,,^..^,,,_ (phone)
On Apr 23, 2016, at 9:54 AM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Fabio,
On Apr 23, 2016, at 9:40 AM, Fabio Niephaus lists@fniephaus.com
wrote:
Hi all,
Bert already mentioned that I've been working on migrating the
repository from SVN to Git.
I believe there are three problems that need to be solved here:
- Migrating SVN externals for sharing code between branches
This is currently used to share a few directories (e.g.
platforms/Cross/plugins) across different
branches. But Git does no support this kind of code sharing.
Instead, it supports submodules [1]
and subtrees [2]. I would suggest to move code that we want to share
into separate Git
repositories and include them as submodules. I think submodules are
easier to understand
(GitHub integrates them nicely in their UI). The only drawback: if
someone updates code in a
shared repository, one needs to update all references to this
repository as well. But I'd say this
is also a good thing: if someone changes e.g. a plugin and the
change is compatible to Cog,
but incompatible to the interpreter vm, then the interpreter branch
is not automatically broken
as soon as one pushes the plugin change. If the above is unclear,
I'm happy to explain
submodules in more detail.
- Versioning and new releases
If we migrate to Git, I'd recommend to deprecate the way we do
versioning in SVN. Instead, we
should use Git commit hashes and Git tags.
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?
Let's say we want to release a new version, we tag the commit of interest with e.g. v1.0.0. When building the Cog VM on
this tag, the version will be
v1.0.0. If we use GitHub, we might as well use a CI service such as
Travis CI [3] to automate the
build process. That means, each time someone pushes changes to
GitHub, Travis CI will build a
new Cog VM (we can call this "bleeding edge"). Let's say I push
changes right after the release
of v1.0.0, the version for the next build will be something like
v1.0.0-37553a9 with "37553a9"
being the short SHA1 identifying my latest commit. If we want to
release e.g. v1.1.0, we just tag
a newer commit and GitHub/Travis CI does the rest for us. I already
have this working, you can
find a Travis build at [4] and the result at [5]. Obviously, we can
push the binaries to a different
server.
- Keeping a copy of the code
We of course want to keep a copy of our code at all times in case
something happens with
GitHub. There are already tools that we can use to automate this.
However, I wouldn't try to keep
the old SVN repository in sync. I believe this might be quite
difficult and I don't see a reason to
maintain something we want to deprecate in the first place. Anyway,
it should be fairly easy to
set up a tool that creates a backup on one of our servers whenever
we change code on GitHub.
Doing a migration from SVN to Git(Hub) takes a few hours and I'd
recommend we stop pushing
code to the SVN as soon as we start to migrate. This obviously
requires everyone working with
the code base to switch to Git. So please let me know if everyone is
comfortable with the
migration. If we want to do this next week, I'd recommend to do it
on a Thursday or a Friday,
because I would be able to do it with Bert sitting two rooms next to
me :)
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.
I hope I have thought about the important things and I'm happy to
answer any questions you
might have.
Best, Fabio
http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree...
[3] http://travis-ci.org [4] https://travis-ci.org/fniephaus/squeak/builds/119507180 [5] https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/
--
On Sat, Apr 23, 2016 at 5:10 PM David T. Lewis lewis@mail.msen.com
wrote:
On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:
I have to admit that I did not even know that an active git svn
bridge
was possible. It sounds like this it might be very helpful.
It would be great to have the advantages of git for development, and it could also be helpful to be able to have the squeakvm.org repo
updated
periodically from git. There are portions of the platforms tree that
Eliot
has been able to make identical for oscog and trunk, and this seems
like
a worthwhile effort to continue.
Another possible advantage is that Ian's cmake build process takes
advantage
of the SVN revision numbering, and it would be good to make sure
this stays
healthy as development proceeds (it's a lot nicer than autotools).
Eliot, do you have a view on this?
Dave
_,,,^..^,,,_ (phone)