smxi sgfxi svmi :: developers
set development options
See sticky options for standard user options. This section is just for advanced dev stuff.
Remember, always start with the latest bunch of script files from the script svns: smxi, sgfxi, svmi (and latest project, inxi). These can and do change rapidly at times, while at others the stuff is largely stagnant. Take a look at the source -> changes to get a feel for the current speed of development. Currently nobody has svn write access but me, the author, but if someone commits enough code, and it's done to the style of smxi/sgfxi, and it works, is a real improvement, is debugged, fits the logic, etc, that could change in the future.
Please do not use any of these options unless you have a good idea of what you're doing
These are useful for working on the script and setting various hardcoded values while you debug and hack etc.
One big advantage of using these is that you won't accidentally include these tests and flags in the working script itself.
smxi sticky options
Sometimes you might want to always use an smxi option, or change some other value in smxi. Now you can do this easily, by simply adding an smxi option file, like so:
# create the file first, as root in terminal touch /usr/local/bin/smxi-values
-
sets any conditions that are triggered by the
if [ "$B_TESTING_1" == 'true' ] then run some test condition fi
B_TESTING_1='true' # same as: smxi -! 1
-
kills the self updating feature of smxi
SKIP_RESTART='true' # same as: smxi -R
-
kills all library file self updating, as well as script updating. Good if you're working on some library file and you want to make sure it doesn't get overwritten.
DEV_FLAG can only be manually set in the script globals section, it has no startup option.DEV_FLAG='true'
You can also change any default paths or file names if you want to do something like for example run a dev version live off your own web server, and so on.
Since these scripts do not use any hard coded paths or values in general, and everything is set in the top globals, you can quite easily modify anything you want in terms of locations, file names, etc.
sgfxi sticky options
sgfxi is a lot harder to work on than smxi because it has to handle such constantly changing circumstances. Let's face it, non free drivers on free systems just suck. But we have to live with it for now.
I've built in a series of advanced options to help test and debug certain components. Please do not use any of these options unless you have a good idea of what you're doing
These are useful for working on the script and setting various hardcoded values while you debug and hack etc.
One big advantage of using these is that you won't accidentally include these tests and flags in the working script itself.
First, make sure you have the file:
touch /usr/local/bin/sgfxi-values
And here are the normal dev options for you to use:
-
first, of course, kill the script autoupdating feature so you won't accidentally get the latest version while working on your version
B_SKIP_RESTART='true' # same as: sgfxi -R
-
This triggers any testing behavior, including the set_test_data() function, which lets you give sgfxi alternate hardware information, and changes the download directory so you can run this stuff as user, not root.
B_TESTING_1='true' # same as: sgfxi -! 1 B_TESTING_2='true' # same as: sgfxi -! 2 # both B_TESTING_1 and B_TESTING_2 same as: sgfxi -! 4
-
The second is always used in combination with B_TESTING_1='true', and triggers a test download of a run file, unzips it, and applies any patches to it.
sgfxi exits after this is done. But remember, don't use this on a system with an active non free driver, since sgfxi strips out the stuff automatically before it runs. Best done in a vm, to simply vefify a download url, a patch, etc, works.B_SKIP_FUNCTION='true' # same as: sgfxi -! 3 # both B_TESTING_1 and B_SKIP_FUNCTION same as: sgfxi -! 5
-
if you want to emulate the behavior of sgfxi when it's run from smxi, you can add the smxi launched flag. This changes default script colors, and a few other things.
B_SM_INSTALL='true' # same as: sgfxi -D
-
if you are testing an install to kernel feature, then set the kernel make sure the kernel exists, because if you do this, you're bypassing the installed kernel test.
INSTALL_TO_KERNEL='<full kernel string>' # example: INSTALL_TO_KERNEL='2.6.25-2' # or INSTALL_TO_KERNEL='2.6.26-3.slh.4' # same as, for example: sgfxi -K 2.6.26-3.slh.4
-
if you're testing one driver, and want to always override the sgfxi default
DRIVER_OVERRIDE=177.68 (for example, or, for fglrx) DRIVER_OVERRIDE=8-7 # same as, for example: sgfxi -o 177.68
-
to make it all non-interactive, just run automatically each time, do this:
B_AUTORUN='true' # same as: sgfxi -A
svmi sticky options
svmi has a very limited set of useful dev options, but here's the ones you might find of use utility.
First, make sure you have the file:
touch /usr/local/bin/svmi-values
-
first, of course, kill the script autoupdating feature so you won't accidentally get the latest version while working on your version
SKIP_RESTART='true' # same as: svmi -R
-
trigger any testing features
B_TESTING_1='true' # same as: svmi -! 1
-
this isn't really implemented in svmi, but the flag is available. If required can be an additional testing trigger for different cases you want to work on.
B_SKIP_FUNCTION='true' # same as: svmi -! 3
And that's about it for the standard dev type options for these scripts.
More advanced methods and tricks
While I'm sure people will at some point come up with weird uses for these source files, some things that pop in my head as possible options is to change the script home, change the script source url, and so on.
For sgfxi testing, please also first read set test data, which explains how to use the built in testing and debugging options in sgfxi.
# note: no / after last directory SCRIPT_HOME='/home/fred/devdir' SCRIPT_NAME='temp-name' # note: / after last dir for download urls # for smxi/svmi/sgfxi values files SCRIPT_DOWNLOAD='http://localhost/distro/'
I'm not suggesting or recommending this type of tweaking, but it is something you can do for various tests, running your own patches, or whatever. Play around with it, I don't care, as long as you can handle the messes you might make, do whatever you want.