World: r3wp

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.

That is a process and as such language and toolchain agnostic.

Continuous integration is really a separate dimension from automation... 
it's a set of objectives for more frequently producing test targets.

If that's what you're suggesting, I'm all for it.

Yes, that's what I am suggesting.

Automated builds, automated testing, automated release packaging.

Revision control, test suites, rapid/daily builds, easy downloading 
of results.

And whatever you want to call it, the process is simple: you have 
a single code base, version controlled. Upon every change to this 
code base, you automatically build and test on all supported platforms.

Yes, exactly. But not "rapid" or "daily" builds, automated builds.

Without human intervention. You commit a piece of code, and automagically 
7 machines pick up the changes and start building.

Continuous integration is really a separate dimension from automation.

We've been doing that since 1999.

Build automation and test automation is one integral part of modern 
CI.

carl, I have to go now... take a peek at the private messages... 
I'll pick up later.

M: ok

BTW, Jeff Kreis (at REBOL) wrote the system we used for full cross 
platform networked automated builds.

Time to get that going again for R3.

You're probably right.

Back then we did it internally and used our own method. But, by now, 
there must be some external method that will work, right?

Some of that was the goal of DevBase... but there are only so many 
hours in a day.

It's all doable.

The other important issue is that easy rollback (revert) is required.

And if we don't reinvent the wheel at every step, it'll probably 
be done sooner rather than later.

I don't think we need to invent anything for this part of it.

E.g. we still use makefiles... works fine.

The first step is having the sources version controlled.

And DevBase would not be my first choice for that ...

And as you obviously want to maintain the closed-source nature of 
libr3, that step will already require a bit of work.

WRT the tools, we go down this road every year or so... but what 
happens is that no good solution is found.  However, I remain open 
minded.