World: r3wp

(If that's what you meant.)

I would probably remove the "clients" table for now.

And add a link to http://www.git-scm.com/downloadinstead.

Along with the recommendation to use msysGit for Win32.

link added, table removed

msysgit note/link added

so, msysgit for windows uses google, not github?

that's not much of an endorsement

they only host their downloads there.

ok, so doc is completed... need only to change the URL once A110 
is posted

I hope it can be done today... tight timing.  If not, it will get 
delayed to Thurs.

Well, do you have more time on Thursday?

Yes. But I want to try to get it out today.

I think the primary question is how we want to bundle the libraries.

yes

I thought about putting libraries for all platforms in a directory 
structure below lib/ .

Either using the platform numbers or the more descriptive names.

There are advantages to both methods... which is why I ping pong 
on them.

it should be "cheat sheet" not 'cheet sheet" http://www.rebol.com/r3/docs/git.html

fixed

http://github.com/carls/R3A110

This is a temporary test area for the release... until we get it 
how we want it.

Andeas: take a look at R3A100, and let me know your comments. There 
are some issues:
1. how best to handle the libs dir for multiple platforms?
2. should we merge the makefiles into a single dir?

3. should about.txt be renamed to README ?

Sounds like a good idea.

3. Yes.

1. The easiest way for now will probably be a directory hierarchy 
under lib:
lib/1.3/libr3.so
lib/3.1/r3lib.{dll,exp,lib}
lib/4.2/libr3.so

We can always restructure that later on.

2. I'd drop all makefiles you did not personally test/use, for now. 
I just assume that means only make-gcc will remain. Then either leave 
that in make-gcc/ or move it to the toplevel again.


But I would not fuss about the makefiles much, same thing here: we 
can restructure that later on.

Don't forget lib/2.5/libr3.dylib

Great stuff, though! Congrats!

But I gotta run now. Will be back in an hour.

why do we mess with git location?

It's not the final location. It's a test, to get feedback on the 
layout of the source files before we release to the final location.

what will happen if I pull into the directory of earlier git synced 
stuff? Will it mess new things into old things, or will it delete 
earlier stuff and replace it wit new?

Andreas? Learning git is still on my todo list for this week.

I think I will be more safe to just purge the directory befor syncing, 
as I don't introduce any changes to local files myself. OTOH I might 
do some small scripts for testing, and would like to not loose them 
...

I want to achieve following workflow:

- new files are added

- files with the same name replace old ones (no mater if I edited 
them)

- non-used files which are not part of the distro anymore, are deleted 
(no matter if I edited them)

- files which are not part of previous nor recent distro (e.g. my 
testing scripts) stay untouched ....

Pekr, no need to purge.

You can pull from multiple remote repositories into a single local 
repository.

what will happen if I pull into the directory of earlier git synced 
stuff? Will it mess new things into old things, or will it delete 
earlier stuff and replace it wit new?

You can choose.

If you have local commits which are not in the remote repository, 
if you _pull_ Git will try to merge your local changes with the remote 
changes.

If you want to always choose the remote changes, do not pull but 
_fetch_ and _reset_ instead.

And rest assured that your desired workflow is perfectly achievable. 
I'll describe how later, gotta run again, unfortunately.

Pekr, there's no need to purge, but it is a good idea to do that. 
 There have been various changes, some of which will not merge properly.

Ok, so far we have:
1. change about.txt to README -- for consistency
2. change lib to use sub dirs per platform

3. move gcc makefile to top dir (and ignore other makefiles for now)

Let me know if there are any other revisions before we move to the 
final directory.

changing my previous suggestion for 3.:
3. drop non make-gcc makefiles for now
4. move the gcc makefiles to sub dirs per platform

additionally i'd suggest the following revisions:
5. remove reb-to.h, pass TO_<target> as compiler flag
6. fix bug#1658: link linux binaries against libdl

suggestion #5 allows to build for different targets from exactly 
the same sources. so we can easily bundle multiple makefiles for 
different targets, which simply pass the appropriate TO_<target> 
flag.


an alternative would be to have target-specific include directories 
(such as src/include/3-1/), place the reb-to.h there and then have 
makefiles for different targets adjust their include paths accordingly.

i have commits for all the above suggestions locally. as they're 
only modifying generated files, i'm not sure they'll be of much use. 
if it helps in more clearly defining what i mean by the above, i'll 
happily push them somewhere public.