Euphoria
Ticket #500:
Clean up the UNIX build setup system
-
Reported by
jeremy
Dec 05, 2010
It doesn't seem as though we need to be defining EBSD, EOPENBSD, ENETBSD, ELINUX, EFREEBSD, EOSX, ...
Most things could be be done w/EUNIX. Some are still needed, but translating to a new platform requires all sorts of additions to the T, I, E and plain XYZ type variables. It doesn't seem that it should be so.
I do not know this for a fact but it just seems like there should be a better way.
Details
1. Comment by SDPringle
Dec 21, 2011
Rather than having a hell of a lot of boolean variables, we can use host_platform() and compare it to the various standard constants or even use switch statements. Also, the various U... constants have been redundant ever since we decided to change the FREEBSD variable to be distinct to LINUX. This is internal to the source, and wouldn't change the behavior of EUPHORIA. I don't see why this shouldn't be a change in 4.0.
2. Comment by mattlewis
Dec 21, 2011
I'm not convinced that we need to do this (but then, I haven't thought a lot about it). There are some specific things that we do, both in eu code and the C code that rely on the platform information. If we can simplify this, I suppose it makes sense.
I think part of the problem is the simplicity of the euphoria ifdef system. We cannot set ifdefs to values, so we can only use the equivalent of a boolean ifdef condition.
I would keep any changes related to this out of 4.0, though. 4.0 builds just fine, and we're really only doing bug fixes there. The 4.0 and 4.1 build infrastructure have already diverted significantly due to ARM and x86-64 architectures.
3. Comment by jimcbrown
Dec 21, 2011
I agree with mattlewis, 4.0 has only one or two releases to go before 4.1.0 is out. The work is best done in the 4.1 build system. (In its own branch as a proof of concept first, of course, but after that...)
The E,T etc stuff is all in run time variables and predates 4.0 and the ifdef statement. It sure is ugly, though - and can probably be done a lot better now that we have ifdefs.
(Considering how long delayed 4.0.4 has been, maybe we should just skip it and release 4.1.0 instead.)
4. Comment by mattlewis
Dec 21, 2011
I don't believe the I* and T* stuff can be replaced by ifdefs. Certainly not the T*, which are important for cross translation. Maybe the I* variables, since I think the platform under the interpreter is defined by the actual interpreter.
Possibly, we need those for shrouding. With ifdefs, shrouded code really isn't portable any more.
5. Comment by jimcbrown
Dec 21, 2011
I'm ok with replacing part of the system with ifdefs if that's feasible.
If not, that is if using ifdefs doesn't help us out here even one iota, then I still don't have an issue with seeing a redesigned system that's less ugly than what we have now.
Of course, what we have now, warts and all, might actually be the best. If so, I'd consider the day that was realized to be a very sad that ... but we should stick with what's best.
6. Comment by SDPringle
Dec 21, 2011
ifdefs do not mix well with if statements. Replacing with ifdefs would be going in the wrong direction. We can eliminate all but two of each of the T, I, and E statements. So we only have a generic UNIX (all OSes like UNIX) and a generic WINDOWS variables (both address sizes). I suppose these were created to avoid typing in if conditionals. This is a consequence of not having switch statements in a language.
GitHub