World: r3wp

no need to compile anything, there are example scripts and compiled 
versions  in the cgr-apps of that zip file.

this being said I would like to have a private chat with you about 
some issues I encountered so far.

A: The OS/dirs are for code that is really quite different.  Merging 
into a single source does not help keep it in sync, because most 
coders only modify the platform of their choice. They can just as 
easily diff.

(Let's just say I've been doing source control for a long long time. 
;)

Maxim: on OpenGL, that's good news.

Checking Steve's bug postings.

Carl, the codebase is already out of sync. Viz. the hostlib vector.

And from inspecting the differences between the Linux and Win32 hostkit, 
there are not really any.

Except for the hostlib vector and 3 or 4 minor lines.

But maybe you misunderstood the suggestion.,

I'm not saying to change much compared to what is done currently, 
as the codebase is 99.95% the same in the past Win32 and Linux hostkit 
releases.

Just to get rid of this artificial distinction alltogether, and keep 
the hostkit a single distribution, from which all platform targets 
can be built.

Makes it _much_ easier to build and test for multiple platforms.

Just checked: there is in fact not a single significant line of difference 
between the Linux and Win32 hostkits, except for the hostlib vector. 
So why not concentrate on a single distribution from which both targets 
can be built.

But what's really more important: any chance to see a libr3.so for 
Linux soon?

Andreas: the host-lib vector is identical on both.  Steve mentioned 
that you were adding some funcs to it -- that is not correct.

Well, I fear that is not true.

How so?

Diff your own releases and you will see.

Here's the diff of host-lib.h in between Win32 A107 and Linux A107:
https://gist.github.com/353ad14fedab30dddd83

libr3 on Linux and Amiga expects a hostlib vector of size 33, r3.dll 
on Win32 one of size 31.

I reported that back for A102.

There's something wrong with that diff... where did you get Linux 
A107 host-kit?

http://www.rebol.com/r3/changes.html

There's nothing wrong with that diff, it's been that way since A102. 
And it still is that way in A109.

But don't take my word for it, diff the downloads you provide on 
your site.

Well, there is a problem, because the libr3.so must be in sync.

libr3.so is in sync with the hostkit sources. It's just not in sync 
with r3.dll.

I'd say just hold off right now... I'm going to be changing the host-kit 
release mechanism very soon.

Looking forward to it ...

And once again: I'd be happy to help you with builds, automated builds 
and automated testing for R3.

There will be a host-kit release archive, then there will be the 
separate dll/so objects in a table.

The issue is that the builds are automated to a whole other level... 
beyond what you are seeing in the host-kit source.

I can only judge what I see.

Correct. You're seeing a snapshot.

And from what I see, there is not much automation.

The automation I am speaking off would automatically build and test 
for all supported platforms on each commit.

Yes, we are talking different types of automation.

That is the only automation that matters, though.

Would have saved you hours of time in the course of R3 alone.

Which one?

Huh?

I don't think so.

The automation you are talking about is classical language based. 
That's fine. We should use as much of it as we can.

But, if you grep the .h files, you'll notice that various ones are 
generated, not created by hand, and that's just the host-kit side.

The automation I am talking about is language agnostic.

The fact that the host-lib is out of sync is an interesting puzzle. 
In theory, that is impossible to have happen if a /Core is released 
along with a /Host-Kit.

I understand. You're talking about makefile automation. The build 
process is far more complex than that.

No, I am talking about automated builds.

And automated tests. The kids call it "continuous integration" these 
days.