[!REBOL3 Source Control] How to manage build process
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.
Andreas, it is easy to move the TO-* to the command line. It was originally put in a file to try to keep the gcc line shorter (easier to see compiler warnings.)
On #6, I thought it was there now, but will check again.
There are more standard and automatic ways to detect target platforms, such as using the available __LINUX__ and __SYLLABLE__ defines
Hm, I think the wrong Git service was chosen. gitorious.org uses Guru meditation error messages:
Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 328580510 Varnish cache server
Kaj, __LINUX__ and such defines are not enough, due to the various incompatibilities between linux systems.
Also, it should be noted, that although most developers often use the most recent versions of their OS, most "normal users" do not. Or, said another way: I have friends who run businesses that just support very old operating systems for very large companies... e.g. ATT as an example.
So, it's nice if we can compiler to older versions.
True, but as far as I know, there's currently only one source configuration for Linux, and you can always supply manual hints for subversions when necessary. In any case, there are also ways to detect such subversions
Maybe I should say sub-types
It's better for the config to be higher level in the master build tables which are defined in REBOL. Those tables define more than just GCC compile time symbols, but also code/data within the boot scripts used by the interpreter.
That is, top down.
Well, there are detections available at that level, as well, such as the uname command on Unixy systems
This is the old debate of table-based configuration systems versus detection-based configuration systems. I understand that tables are less work at first, and so that's what everyone did in the old days, but exactly because environments are so complex these days, most people have moved to automatic detection
In my experience of porting software to more or less deviating platforms, table-driven systems are harder to work with than ones with proper detections
The goal of the current R3 build automation method is to save my time. Currently, the platform table is only ~10 lines of REBOL, so it is difficult to beat using any other method. And, even with the detection approach you mention, you need still tables. However, that being said, if you want to create and test such a detection-based method and confirm it works over a range of OSes I would be happy to use it! It must handle Linux, Syllable, BSD, OS X, Solaris, Windows, AmigaOS, Haiku, QNX, and various others, and also work for systems ten years old or more. I'm open to any idea like this... as long as it saves *me* time.
I can't test it myself on most of those systems, but I'll keep the idea in mind when digging further into the host kit. There are a few well known configuration systems that are much too bloated to use, but that are good sources to collect the tests needed on systems that I don't have
It's currently not a big deal, but it would be nice to eliminate the manual configuration requirement
Right now, the manual configuration doesn't take much time, because we're building only /core and /libr3... and for posix model. Once more features are added, like graphics and sound, or specific OS support (e.g. like what Solie is doing) then we'll need to revisit it.
BTW, here is an example of the entire config used for 4.2 (Linux): [0.4.2 "linux" posix [LDL] [CO1 F64 HID NPS] [ST1]]
LibDL... what do the others mean?
-O1, 64 bit files, vis=hidden, no-ptr-sign, strip result
I've started to use git, I downloaded the A110 yesterday... yay!
(user moliad on github)