World: r3wp
[!REBOL3 Source Control] How to manage build process
older | first |
Kaj 5-Nov-2010 [639x2] | 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 | |
ssolie 5-Nov-2010 [641] | Appropriate :) |
Carl 5-Nov-2010 [642x5] | Nice! |
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. | |
=compile | |
Kaj 5-Nov-2010 [647x2] | 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 | |
Carl 6-Nov-2010 [649x2] | 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. | |
Kaj 6-Nov-2010 [651x3] | 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 | |
Carl 7-Nov-2010 [654] | 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. |
Kaj 7-Nov-2010 [655x2] | 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 | |
Carl 8-Nov-2010 [657x2] | 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]] | |
Kaj 8-Nov-2010 [659] | LibDL... what do the others mean? |
Carl 10-Nov-2010 [660] | -O1, 64 bit files, vis=hidden, no-ptr-sign, strip result |
Maxim 10-Nov-2010 [661x2:last] | I've started to use git, I downloaded the A110 yesterday... yay! |
(user moliad on github) | |
older | first |