develop branch

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Fri Sep 26, 2014 7:45 pm

I just saw Trevor's pull request for MCRedrawUnlockScreen(), and that's against the develop branch. Should I be issuing pull requests against develop and just assume they'll be merged into refactor? That would solve my problem if so, but I just assumed from the earlier discussion here that it wasn't a good idea to issue PRs against develop.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: develop branch

Post by LCMark » Fri Sep 26, 2014 8:18 pm

@mwieder: Well Trevor's is a bug-fix for a regression introduced in 6.7 which is why it's against develop.

Your pull request is for a new feature, and as we at RC in both 6.7 and 7.0 we generally try and avoid adding features during this phase (as we want to get to stable as soon as possible). So ideally, all new feature's should be done against 'refactor' with a view to them being merged in for a '7.1' after 7.0 goes GM (6.7 and 7.0 will GM at the same time).

I had intended to re-review your one for ceiling and floor as well as @monte's (he submitted one for metadata of image property) this week to see if it would be okay to slide them into 6.7 at this stage (it does depend on how long the RC period still has to run). Doing this does have a time impact on merging into 7.0 since this has changed how execution, syntax and property definition works to a good degree. Our time has been a bit stretched this week with getting iOS 8 support working so I haven't had a chance to do this, however.

Anyway, we'll be reviewing where we are with the RC's early next week, so perhaps hang-fire for the moment and I'll let you know - if we have a small amount of 'spare' engineering time to allow this then I'd prefer to see them in sooner rather than later.

EDIT: I should perhaps say that we are in a bit of a 'grey' area at the moment insomuch as refactor (7.0) is significantly different from develop (6.7) - things will become a great deal clearer after 7.0 goes gm because 'develop' will then be the new architecture we've introduced (i.e. 'refactor' gets merged into 'develop').

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Fri Sep 26, 2014 10:30 pm

Thanks - I don't think the floor() and ceil() additions are at all urgent.
My concern is just that I can't compile the refactor branch, or rather can't generate the prebuilt artifacts, but I *can* compile the develop branch. For my pull request here, I think it would be better to go against the refactor branch, since I know Ali has done some similar refactoring work on the math classes, and it would be nice not to have two different approaches to subclassing for the two branches.
I seems to be at a standstill, but I've got other things to fill my time right now until this can get resolved, so no worries.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Sun Sep 28, 2014 2:16 am

Progress: line endings are indeed a problem. At least for me. I had my global config set to core.autocrlf=true.
Works a lot better when I set it properly. :oops:

All libraries now downloaded and extracted, and I'm running a make on the refactor branch now.

and Update: success in building against the refactor branch. Now to merge my feature branch from the old repository.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Sat Oct 04, 2014 6:22 pm

It's getting to the point where I think I'm the only one who attempts to build off different branches. To wit:

I can build off the master branch.
I can build off the refactor branch.
But not both. I have to have two separate repositories to do this.

Switching to the develop branch from the master branch and building results in
./src/core/Sk64.cpp:1:0: error: CPU you selected does not support x86-64 instruction set

After the 30 September submodule tweak to the prebuilt submodule ("update prebuilt submodule pointer"), attempting to switch from master to refactor results in
error: The following untracked working tree files would be overwritten by checkout:
<followed by a list of many prebuilt files>
I'm not sure this is much of a step forward from the previous situation, where attempting to checkout refactor gave
warning: unable to rmdir prebuilt: Directory not empty

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Wed Oct 29, 2014 6:55 pm

Right.
Now I could use some guidance as to where to submit pull requests.
It seems that the refactor branch is no longer the LC7 main trunk. Nothing much has happened there lately and the release-7.0 and release-7.0.1 branches are getting new love from many different branches.

Previously, the master branch was being used to build the 6.6 series, the develop branch was for ongoing work on the 6.7 series, and the refactor branch was for the 7.x series.

I see lots of notifications about new features and bugfixes, but I pulled the refactor branch for the first time in a week and there's nothing new there.

So what branch should new branches be based on, and where should pull requests be issued against?
I also asked this question last week on the develop list but got not answer.

LCfraser
Livecode Staff Member
Livecode Staff Member
Posts: 71
Joined: Thu Nov 28, 2013 11:18 am
Contact:

Re: develop branch

Post by LCfraser » Thu Oct 30, 2014 10:41 am

@mwieder:

We're currently in the middle of re-jigging our git branches and haven't quite finalised the scheme yet. I'll follow up to this post with details of how we're managing things once we know ourselves... one thing that we're (fairly) certain of is that "refactor" will no longer exist - it has served its purpose and is no longer required.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: develop branch

Post by LCMark » Thu Oct 30, 2014 6:48 pm

@mwieder:

We'll be posting (and updating) docs related to our branch policy over the next few days. However, essentially we have now restructured the main LiveCode repo (submodules still to do) in the following way:

'master' has gone, being replaced by 'master-6.7' and 'master-7.0'. The latter two branches track stable point releases of those two major versions.

'develop-6.7' and 'develop-7.0' have been added. These two branches are the frontier of development for maintenance releases for these two major versions.

'develop' is, as it always was, the frontier of development for the next major version.

If you want to add a feature, it should be done against 'develop' (unless there is a case for, and it has been agreed that, it should be back-ported to an existing major version).

If you want to fix a bug that has been introduced in 'develop', it should be done against 'develop'.

If you want to fix a bug that is present in 6.7, it should be done against 'develop-6.7'.

If you want to fix a bug that is present in 7.0 but not in 6.7, it should be done against 'develop-7.0'.

The main reason for these changes is to make it easier to maintain more than one existing major versions through the point release updates we have been doing; and so we can move to a merge-early-and-often strategy with pull requests. i.e. We'll merge into the relevant develop branches as soon as they have been reviewed, rather than bunching them up at the points we do a 'dp' or 'rc'.

PS: Apologies for any pull requests that were inadvertently closed - that was github being 'clever', and wasn't intentional. Please resubmit any relevant ones against the appropriate branch outlined above.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Tue Nov 18, 2014 5:31 am

<sigh>

still trying to get the develop branch to compile.
valgrind is now on the list of prerequisites.
Not a big problem, but it's something new that was added.
So after apt-getting valgrind in the mix I end up with

In file included from ./src/cairo-analysis-surface.c:37:0:
./src/cairoint.h:2827:22: fatal error: memcheck.h: No such file or directory
#include <memcheck.h>

...so I see that memcheck.h is at
~/livecode/thirdparty/headers/linux/include/valgrind/memcheck.h
/usr/include/valgrind/memcheck.h

but neither of those is in my include search path.

So I bit the bullet and cloned yet again a new local git repository from runrev/livecode.
And ran a make all.

mkdir -p ./../_build/linux/x86_64/debug/
g++ -fvisibility=hidden -o./../_build/linux/x86_64/debug/server-dbmysql.so -L./../prebuilt/lib/linux/x86_64 -shared -Xlinker --exclude-libs -Xlinker libcustomssl.a -Xlinker --exclude-libs -Xlinker libcustomcrypto.a -Xlinker -no-undefined -static-libgcc ./../_cache/linux/x86_64/debug/server-dbmysql/dbdrivercommon.o ./../_cache/linux/x86_64/debug/server-dbmysql/database.o ./../_cache/linux/x86_64/debug/server-dbmysql/dbmysqlapi.o ./../_cache/linux/x86_64/debug/server-dbmysql/mysql_connection.o ./../_cache/linux/x86_64/debug/server-dbmysql/mysql_cursor.o ./../_build/linux/x86_64/debug/libmysql.a ./../_build/linux/x86_64/debug/libz.a -Wl,-Bstatic -lcustomssl -lcustomcrypto -Wl,-Bdynamic -lpthread -ldl -lm
/usr/bin/ld: cannot find -lcustomssl
/usr/bin/ld: cannot find -lcustomcrypto
collect2: error: ld returned 1 exit status
make[2]: *** [../_build/linux/x86_64/debug/server-dbmysql.so] Error 1

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Thu Nov 20, 2014 4:48 am

Maybe I'm not supposed to build the prebuilt artifacts:

prebuilt: develop$ ./build-libraries.sh
Fetching Curl source
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2674k 100 2674k 0 0 17961 0 0:02:32 0:02:32 --:--:-- 22948
Unpacking Curl source
Duplicating Curl source directory for linux/i386
Configuring and building Curl for linux/i386
failed
Fetching OpenSSL source
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4403k 100 4403k 0 0 95440 0 0:00:47 0:00:47 --:--:-- 70531
Unpacking OpenSSL source
Duplicating OpenSSL source directory for linux/i386
Configuring OpenSSL for linux/i386
Building OpenSSL for linux/i386
failed
Fetching ICU source
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 354 100 354 0 0 488 0 --:--:-- --:--:-- --:--:-- 488
Unpacking ICU source
tar: This does not look like a tar archive

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
mv: cannot stat ‘icu’: No such file or directory
Creating ICU build directory for linux/i386
Configuring ICU for linux/i386
Building ICU for linux/i386
failed

But since I'm not that concerned about building the 32-bit libraries I'll let that go.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Thu Nov 20, 2014 5:07 am

Meanwhile

cc -fPIC -g -fvisibility=hidden -I./src -I../../engine/include -I../../libfoundation/include -I../../lcidlc/include -I../../libcore/include -I../../libexternal/include -I../../libgraphics/include -I../../thirdparty/libiodbc/include -I../../thirdparty/libjpeg/include -I../../thirdparty/libmysql/include -I../../thirdparty/libpcre/include -I../../thirdparty/libpng/include -I../../thirdparty/libgif/include -I../../thirdparty/libpq/include -I../../thirdparty/libsqlite/include -I../../thirdparty/libxml/include -I../../thirdparty/libxslt/include -I../../thirdparty/libz/include -I../../thirdparty/libzip/include -I../../thirdparty/libopenssl/include -I../../thirdparty/libcurl/include -I../../thirdparty/libskia/include/core -I../../thirdparty/libskia/include/config -I../../thirdparty/libskia/include/effects -I../../thirdparty/libskia/include/images -I../../thirdparty/libskia/include/pathops -I../../thirdparty/libskia/include/ports -I../../thirdparty/libskia/include/utils -I../../prebuilt/include -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/harfbuzz -I/usr/include/gtk-unix-print-2.0 -I../../thirdparty/headers/linux/include -I../../thirdparty/headers/linux/include/cairo -D_LINUX -DTARGET_PLATFORM_POSIX -D_FILE_OFFSET_BITS=64 -D_DEBUG -DHAVE_VALGRIND -D__LITTLE_ENDIAN__ -MMD -MF ../../_cache/linux/x86_64/debug/libcairopdf/cairo-analysis-surface.d -c -o../../_cache/linux/x86_64/debug/libcairopdf/cairo-analysis-surface.o ./src/cairo-analysis-surface.c
In file included from ./src/cairo-analysis-surface.c:37:0:
./src/cairoint.h:2827:22: fatal error: memcheck.h: No such file or directory
#include <memcheck.h>
^
compilation terminated.
make[1]: *** [../../_cache/linux/x86_64/debug/libcairopdf/cairo-analysis-surface.o] Error 1
make[1]: Leaving directory `/home/mwieder/livecode/thirdparty/libcairo'
make: *** [libcairopdf] Error 2

Now, I have memcheck.h in two places:
livecode/thirdparty/headers/linux/include/valgrind/memcheck.h
/usr/include/valgrind/memcheck.h

so I added headers/linux/include/valgrind to rules/common.linux.makefile and I can compile again.
I'll submit a pull request for this, but I don't see how this ever compiled without it. Do the build machines just have this in the path by default?

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: develop branch

Post by peter-b » Fri Nov 21, 2014 10:21 am

mwieder wrote:<sigh>

still trying to get the develop branch to compile.
valgrind is now on the list of prerequisites.
Not a big problem, but it's something new that was added.
So after apt-getting valgrind in the mix I end up with
valgrind is *not* a prerequisite of develop. develop should compile without having valgrind installed, even in debug mode. If it doesn't, please file a bug.

I have no idea why cairo thinks that it should be able to use the memcheck headers if they're not even on its search path. Is there a option that can be passed to its configure script to turn it off?

If you uninstall valgrind and try compiling, do things start working again?
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: develop branch

Post by LCMark » Fri Nov 21, 2014 10:45 am

I'm guessing 'HAVE_VALGRIND' being in the global definitions (linux build rules) will do that :)

So the problem is probably that the memcheck headers which are now in thirdparty aren't being referenced in the include list...

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Fri Nov 21, 2014 5:22 pm

Right. I don't really want to remove valgrind - it's a very useful tool.
Anyway, I submitted the pull request last night, so it's just waiting for approval.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: develop branch

Post by mwieder » Sat Jan 31, 2015 4:08 am

Getting back to building the develop branch after not touching things for a while.

It's no longer possible to just 'make all'... you have to do a 'make bootstrap' first.
And bootstrap has a new requirement that flex be available.
Afterwards it does build properly.

Locked

Return to “Engine Contributors”