World: r3wp

http://bolka.at/2010/rebol3/CMakeLists.txt.html

Looking at above link, I don't think cmake provides much benefit 
to us.

( the current version of Os/2 is ecomworkstation  and is positioned 
as a secure enterprise client environemnt )

Here's the CMake buildfile I use for the A96 hostkit

CMake provides the benefit that we don't have to reinvent the wheel 
for now. It has, for example, a nice installer for Win32 and can 
automatically generate Visual Studio project files from the above.

well, if you are considering a makefile generator, at least cmake 
is somewhat of a standard

Installer? What does it install?

cmake.exe

CMake takes the above as input and generates e.g. a Makefile as output.

Taking specifics of the actual build environment into account.

The method I use for R3 simply uses REBOL to generate the host-kit, 
the makefile, and other related files at the same time.

With CMake the workflow of a user who wants to build the hostkit 
on Win32 would be as follows:
- Download and install a toolchain (e.g. MingW or MSVC)
- Download and install CMake
- Download the R3 Hostkit

- Generate a R3 build script for your preferred toolchain using CMake. 
E.g. use CMake to generate a GNU make Makefile for MingW
- Build the R3 Hostkit (using the generated build script)

Without CMake, those steps would be the same, except for the extra 
installation of CMake and the generation of a local build script. 
But it would also either limit the user to a single toolchain (such 
as MingW, currently) or you would need to replicate some of the functionality 
of CMake in your make-build.r

there's a GUI front end for cmake too, though I guess one could be 
made for REBOL just as easily - this lets you resolve env var issues 
and other things

Further, at least for the A96 hostkit, Linux and Win32 hostkits are 
completely separate packages, and that's an incredible nuisance for 
someone doing cross-platform work.

It built for me just fine but I had to modify the makefile to use 
cp lib\r3lib.dll .
instead of 
copy lib\r3lib.dll . 
inside a mingw cmd window.

Do we have a test files to run to check if all areas of R3 that is 
implemented is working?

It would be good if we had access to the test suites

After adding MinGW\bin and msys\1.0\bin to the windows command path 
and also copying rebol.exe to msys\1.0\bin folder, I was able to 
build it from a normal command window without modifying the makefile.

Carl: in any case, I don't care much about CMake. Just shipping the 
hostkit with your make-build.r instead of a pre-built makefile would 
most likely do just fine for getting an integrated cross-platrform 
build working. (Plus, of course, bundling the libraries and sources 
for all platforms in the hostkit.)

I see go.r can be use as test.

And just in case: _THANKS_ a million for the new hostkit code drop, 
Carl (and everyone else who helped make it happen)!

echo that

yes thanks to everyone who worked on making it happen.  :-)

we now have a domain ( thanks Andreas ) for the tracker http://jira.rebolsource.net:8080/secure/Dashboard.jspa

and now is probably as good a time as any to move this discussion 
to !REBOL3 Host Kit

+1 Thank you!

Apart from Win, OS-X, Linux, BSD, the next most important platform 
is really imo an ARM plus Android.

Put Arm before BSD

BSD is well serviced by R2

I agree - for R3 to gain traction, mobile support should be a priority.

Jira: Why a new tracker? Isn't CureCode still be used? No information 
fragmentation please.

Priorities: Before getting new platforms up & running I see feature 
completion to be more critical. Otherwise we have a moving target 
that takes to much effort to keep in sync.

I agree about the completness-first  argument ...

Robert, if you read above, Carl did not want to make a public release 
unless someone gathered all the comments ... and Andreas & I volunteered.

The curecode tracker does not have a hostkit project ... so I used 
my new Jira tracker.  Simple as that.

Most of the host kit problems are R3 problems as well. We have categories 
in R3's Curecode project, and we can add a Host-Kit category if needed 
(I will do so right now). Multiple trackers are not a good idea, 
in general. We'll see if they become a problem in this specific case.

Done.

Thanks

Could you add an A100 version as well, please?

Done. As with all new versions added, be careful to set that field 
when you write up a new ticket. But we should be careful with that, 
because in general we haven't had prereleases. We may end up with 
problems reported for a100 that will be fixed in a100 :)

I consider the current hostkit drop to be hostkit version A100. The 
next hostkit to be released should (and hopefully will) be A101 or 
later.

Anyone know how to compile in one's own protocols ??

The "current hostkit drop" is not a release, it's a prerelease.

This is getting increasingly off topic.

Carl calls it a release, so I consider it a release. And yes, should 
be in R3 Host Kit

I too vote for an  A101 numbering the next time a package is released... 
its going to be MUCH easier to follow for everyone.   IIRC the A97 
created this strange pre-release condition too and it had to be specified 
each time we talked about what we downloaded.

Robert, did you ever upload your macros stuff that you mentioned 
in Jan?  I looked in the extensions group and didn't see anything

And your sqlite3 extension?

jocko .. your TTS extension still works under A100

No, sorry. Need to bundel all this so it can be used. But it's all 
still to much in flux, not fully-done etc.