Talk:imake
This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
debian ubuntu redhat broken imake
[edit]imake worked for X11R6-4.8, upgrades (up to) "c11++" changed how "cpp" (not the compiler, the preprocessor) processed text. other companies also made "cpp" which didn't work like cpp. (the X stands for Xerox parc)
Because they changed the cpp parser, everything that relied on reliable parsing BROKE, including imake, X11R6, Motif and all software that run under X11R6. Some would say the breakage was not un-intended. It had happened before but had been fixed in the past but the fixes were then broken - even garbage placed craftily in the distributed .cf files. They broke it for their own needs didn't care what it broke elsewhere.
(infact, with a " " spaces filter imake still works using any cpp)
Imake configured X's many build variables and there were many smart "build macros" (see macro) ie submitted for (free)BSD build of X. A program in the tree would merely say what kind of install target it was, it's sources, and macros would take care of all the work (effeciently and correctly - X was known to build on just anyone's system and run well): it compiles then place programs and resources where the X system looked for them RUNTIME. That being said, the system - if you had to "revise it", was not simple when things did fail for the un-initiated. (a quick answer is: don't break it and you wont have to fix it!)
All software (Motif, anything else) would build "under the X tree" because they "were build with the X server" (or a special set of files to tell them how the X server was built, .cf - which Xorg replaced with ".pc"). If you had Xfree and Motif you could build Motif in the X tree or Motif separately feeding Motif the .cf files which tell it the facts about X server it requires, requires an /imports dir with softlinks to developer files ... but result was same out of the tree - by design.
Xorg split X11R6 up into 200 pkgs each with a separate .pc file, but they "don't support many of the packages they split off and have deleted many", which means while X used to come with a minimal set of finished working sofware (like Xterm, Xedit, Xcalc - no depends failures either) it now comes, often, to users with a black screen and no mouse support and users scratching their head how to fix it. They've also hacked the trivial apps so none of the any longer work with X11R6 they are #owned by Xorg. It's a good question since X11 was already modular in every way - why Xorg "needed to replace X11 but in an incompatible way", since anything they wished to add could have been "an extension or module", while instead they chose to prevent all past X11 X10 software from running correctly and making incompatible changes integral (not in the extensions). Video is one (they deleted hw support of usa cards sold). XInput? why delete everyones keyboard and mouse from working when X's Xinput already was designed to support adding exactly any input device whatsoever whatever language? Good question why the sought incompatible damages instead of adding support.
Imake and .cf is still the best way to build and release X11, and all X projects in it's tree, so that projects based on X only "just work"
Imake is far faster and better than automake cmake and other contenders (who are bound to the X11R7 crowd that #kicked X11R6): who are different but not better at getting X and apps based on X compiled installed running correctly and quickly.
.pc are simple headers containing suggested file system placement and versions: they are not macros and do no compiling or installing and are not capable like .cf were (are)
The whole system, make no mistake, was for building X and apps which used X (or X extenions or sub-projects) only. Very little software other than X10, X11 ever used the same methods.