Baseline Development Environment?

DaltonCalford · Post by **DaltonCalford** » Tue Jun 04, 2013 2:11 pm

What is the baseline development environment used by the core Livecode developers?

What OS/Compiler/libraries etc.

I am looking to setup one or more clean room virtual machines as a baseline compile farm, but I want to ensure that I am using the same base libraries, compilers etc that are used by the runrev developers so that I am not introducing new bugs/behaviours due to undocumented differences.

If one of the current dev team could just list the steps they would take to get a factory fresh machine ready to work on the codebase, that would get us all on an even starting position.

best regards

Dalton

LCMark · Post by **LCMark** » Tue Jun 04, 2013 2:21 pm

@DaltonCalford: I added a proper README.md doc to the github repository today which contains all the pre-requisites and information about getting up and running. You can view it here:
https://github.com/runrev/livecode/blob ... /README.md

DaltonCalford · Post by **DaltonCalford** » Tue Jun 04, 2013 2:50 pm

This is a great resource - exactly what I was looking for, but like any good document, it opens up more questions than it answers.

For example, linux - every distribution has a limited life - ubuntu 6.06 is from June 2006. That distribution has not been supported by ubuntu themselves for years. The Ubuntu 10.04 LTS (long term support) release is now out of support as 12.04 LTS replaced it.

Worrying about 6.06 is like worrying about windows me. Who makes the decisions as to what versions of which platforms should be supported? If an engine developer needs to support these old OS versions, means I need to set up test virtual machines for each of them.

What versions of
(make,gcc,g++,libX11-dev,libXext-dev,libXrender-dev,libXft-dev,libXinerama-dev,libXv-dev,libXcursor-dev,libfreetype6-dev,libgtk2.0-dev,libpopt-dev,libesd0-dev,liblcms-dev )
are the core developers using on their machines as this would explain many of the issues I have found running the environment on Linux.

gcc/g++ and the standard libraries have evolved and there are some coding styles that would cause problems if used on newer compilers, while the newer approaches just won't compile on the older platforms.

This means that a great deal of work is required to keep backward compatibility or someone who has control of the master tree needs to draw a line in the sand and state which platforms/OS releases are supported.

Anyone who needs support for older versions would be free to do the work themselves, but, in cutting support for older versions, you cleanup the code base and make it easier to move forward.

best regards

Dalton

LCMark · Post by **LCMark** » Tue Jun 04, 2013 3:50 pm

Worrying about 6.06 is like worrying about windows me. Who makes the decisions as to what versions of which platforms should be supported? If an engine developer needs to support these old OS versions, means I need to set up test virtual machines for each of them.

It isn't so much that we're particularly concerned about running on 6.06, it's just that it has a libc/dynamic linker environment that means binaries built with it run on a wide variety of Linux platforms - something which is not the case if you use 10.04 or 12.04 as a baseline build system.

What versions of (make,gcc,g++,libX11-dev,libXext-dev,libXrender-dev,libXft-dev,libXinerama-dev,libXv-dev,libXcursor-dev,libfreetype6-dev,libgtk2.0-dev,libpopt-dev,libesd0-dev,liblcms-dev )
are the core developers using on their machines as this would explain many of the issues I have found running the environment on Linux.

Well, without knowing the issues you have been experiencing I can't say for sure what might be causing it but I very much doubt it will be related to the versions of any of those packages - given that the header files just describe what system calls are available and since none of the ones the engine uses in those packages have changed in a long time (X, for example is an incredibly stable and slow moving project). After all, once you've built a binary with a version of gcc the principal dependence it has is on glibc - which is a project which seems to be exceptionally good at backwards compatibility. That being said I will check the version of gcc etc. and add that in (I think 6.06 allows you to install a couple of different versions).

This means that a great deal of work is required to keep backward compatibility or someone who has control of the master tree needs to draw a line in the sand and state which platforms/OS releases are supported.

We do - the current list of pre-requisites for running the LiveCode engine is listed in the release notes in the 'Platform Support' section. These are reviewed periodically, but we only tend to drop support for older platforms when there is a significant technical reason to do so.

In the future we have a plan to provide pre-canned toolchains and headers for all platforms that we support so that people can easily produce precisely the same binaries as we do. Hopefully this should mean they can more easily test the work they've done in builds that are identical to those that we produce.

mwieder · Post by **mwieder** » Tue Jun 04, 2013 6:01 pm

@Dalton- welcome to the party.
I've been using various different combinations of make, gcc, g++, etc, depending on whether I'm compiling 32-bit or 64-bit versions of the engine and on which distro I'm using at the time. But I haven't run into any incompatibilities in the source code due to this. Be prepared, though, for a lot of compiler warnings no matter what you use or what platform you're on. I think I clocked 3887 warnings the first time through. Hopefully they'll all disappear with the refactoring.

mwieder · Post by **mwieder** » Tue Jun 04, 2013 6:03 pm

@runrevmark- thanks for the readme file. I know it's a work in progress, but it's a good start. And a necessary component of the repository.

mwieder · Post by **mwieder** » Thu Jun 06, 2013 12:21 am

OK - now I've run into glib problems with the 64-bit compile. I fixed them here in 11 libgnome headers ("only <glib.h> can be included directly"), but I'm having git trouble. I pushed the changes to github (and deleted the pushed branch after discovering...) and ended up with 2600-odd files changed when there should have been only eleven. I'll see about rebasing and do what I can to get a pull request in place.

mwieder · Post by **mwieder** » Thu Jun 06, 2013 3:46 am

OK - I'm stumped with a git problem. I made changes to 11 files in the thirdparty submodule. I pushed the changes to a "fix-glib-errors" branch in my github repository, but I can't seem to get github to allow me to craft a pull request into the thirdparty submodule ("different histories" error). Any ideas?

monte · Post by **monte** » Thu Jun 06, 2013 4:03 am

have you been running git submodule update after pulling

mwieder · Post by **mwieder** » Thu Jun 06, 2013 4:42 am

Yeah, that's not really the problem. It's more that I made changes in a submodule. If I push the main repository and try to issue a pull request to develop I end up with some 2600 changes. If I cd into the thirdparty directory and push I end up with 12 changes, which is right. But then there's no branch in the runrev repository to issue a pull request against.

monte · Post by **monte** » Thu Jun 06, 2013 4:51 am

Hmm... you shouldn't need to send a pull request to livecode for changes to thirdparty. A submodule is just a single file with a sha1hash of the commit it points to. So the pull request is redundant given if it's accepted in third party the change would end up showing up as a different commit in livecode (a merge commit from runrevmark) which would itsself be a child of a merge commit from your change and a local branck runrevmark will create for the purpose.

monte · Post by **monte** » Thu Jun 06, 2013 4:53 am

Regarding the 2600 changes are you sure you didn't branch off develop and issue the pull request against master?

monte · Post by **monte** » Thu Jun 06, 2013 5:02 am

Ah.... you've somehow managed to push the branch off thridparty to livecode... delete the branch from your livecode repo... make sure you remove livecode as a remote for the thirdparty repo then add your clone of the thirdparty repo as a remote then push there... then submit a pull request against thirdparty and it should be good...

mwieder · Post by **mwieder** » Thu Jun 06, 2013 5:53 am

@Monte- thanks. That wasn't it, but it was close enough to get me on my way.

I ended up forking the thirdparty submodule, locally doing a cd into the thirdparty directory, git stashing my changes, pulling from my fork, recovering my stashed changes, committing them, pushing to my fork, and then I was able to issue a pull request against runrev's submodule.

Whew! I'm done for the night.

monte · Post by **monte** » Thu Jun 06, 2013 6:05 am

That's pretty much what I meant for you to do... I think you could have avoided the stashing just by twiddling the remotes on the repo to point to your fork but I'm glad stress is over and you can hopefully get a good night's sleep

LiveCode Forums

Baseline Development Environment?

Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?

Re: Baseline Development Environment?