Computer Mad Science - UnCMake (to rip parts of cmake-d installations)
Posted 04-14-2012 at 07:34 PM by rainbowsally
Updated 08-06-2014 at 10:22 AM by rainbowsally (bug fix)
Updated 08-06-2014 at 10:22 AM by rainbowsally (bug fix)
[See also UsR2usr for creating binary trees without committing to a full install until you can test the installation with this or any other package installer.
http://www.linuxquestions.org/questi...version-34673/ ]
Bug Fix: Apr 24, 2012
[Corrected file names in the main executable. Ouch!]
uncmake-1.1.8 (system) installer/uninstaller
http://rainbowsally.org/rainbowsally...e-1.1.8.tar.gz
After installation try this.
And watch the files change. uncmake.state is the flag file and uncmake.dir contains the path to uncmake.txt dump file.
uncmakefile is also and interesting app. Not as scary, but then it really needs uncmake to do much of anything really useful.
Here's the README.
http://www.linuxquestions.org/questi...version-34673/ ]
Bug Fix: Apr 24, 2012
[Corrected file names in the main executable. Ouch!]
uncmake-1.1.8 (system) installer/uninstaller
http://rainbowsally.org/rainbowsally...e-1.1.8.tar.gz
After installation try this.
Code:
uncmake -set ; ls /usr/bin/uncmake.* uncmake -reset ; ls /usr/bin/uncmake.*
uncmakefile is also and interesting app. Not as scary, but then it really needs uncmake to do much of anything really useful.
Here's the README.
Code:
This is a precompiled binary installer/uninstaller using make. It installs 'uncmake' and 'uncmakefile' utilities for demystifying cmake and other opaque make system builds. To install requires root permissions. It installs all the files into /usr/bin, where we presume gcc, g++, and ld are also. The files TREE is an image of what gets installed minus the PREFIX defined in the Makefile. To install, as superuser type 'make install'. To uninstall, as superuser type 'make uninstall'. ------------------------------------------------------------------ Uncmake -set and -reset switch between uncmake mode and normal mode for dumping cmake commands to a file initially named uncmake.txt in the folder where you execute the 'cmake' command. It requires root permissions in order to switch states. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is a DANGEROUS but very useful application when used with a little caution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% HOW IT WORKS: It will change the names of gcc, g++ and ld depending on the cmake.state (which is a file in /usr/bin that it creates) so that normal gcc, g++, and ld functions can be preempted by the uncmake utility when it is set. Unless you update* while in cmake mode, the original files will be named /usr/bin/cmake.<name>.orig. All of the files involved have the "cmake." prefix. ----------- * There is another potential problem besides updating while uncmake is -set as well. See "NOTE" below. DANGER: What makes it dangerous is that uncmake may be in the wrong state if there's a power outage, or if you reboot while uncmake-ing. It should be possible to 'uncmake -reset' after booting back up, but the output file will be corrupted by anthing that uses gcc, g++ or ld behind the scenes during the boot process. uncmake doesn't depend on cmake. It works with the files named above. And things could get even worse if you upgrade your gcc, g++, or ld while uncmake-ing. There's a good chance you'll have to reinstall them if you ever 'uncmake -reset' after this. If it's already -reset when you upgrade there should be no problem since the files will all be restored to their original 'state' and cmake.state (the state flag file) will have been removed. The best thing to do if this happens is to uninstall uncmake to remove junk files including 'uncmake.state' and reinstall it. No guarantees. That's untested but should probably work. Gcc, g++, and ld are the only files affected. You might want to back them up (whether they are symlinks or regular files) as an extra measure of safety. NOTE that in addition to the above possible gotcha's some other utilities do the same thing to gcc, g++, and ld and these do not play well together. For example, 'checkinstall' may cause problems with uncmake due to unsynchronized changing of these three critical files. (This is unconfirmed but at one time, checkinstall backed up some pretty strange files shortly before a reinstall of gcc, g++, and ld became necessary.) And while the scenarios described such as power outages and updating are fairly rare, this kind of issue with 'checkinstall' or other similar apps could happen just as a matter of not knowing whose the boss in these situations at any time when both are working at the same time. And one more issue to look out for is that ALL gcc, g++ and ld commands will get copied to the uncmake.txt file while uncmake is -set. Even if another user executes commands that invoke these applications. If it's a large file it could be quite time consuming to sift through and remove the unwanted portions of the dump. Best used on a single user system. USEFUL: What makes this useful is that we can see the exact commands cmake and most other make systems are running. And with uncmakefile (included in this package) the output file can be translated into convenient sub-parcels of make commands that can be imported into a makefile in order to work with just one or a small handfull of the files you normally can't get at even if you could find them nevermind edit, debug, or test. For example, did you know that kdesu is created by simply linking kwrapper.o with the output name kdesu? That is not at all obvious but we can see this in an uncmake dump file. Once we know this we can see that kwrapper takes the name from argv[0] and prefixes that name with 'lib' and does the call. Pretty nifty trick. FUN: There are some test<N>.in files in the uncmakefile-sources tarball if you want to see what it does. And there's a copy of the executable in the TREE folder you can copy for testing before committing to installation. Uncmakefile does NOT require root permissions and is quite safe to play with. :-)
Total Comments 0