w32config.cfg or something like that. Sorry not at my machine right now to check. And regarding your other question i bet the -w is the problem there. Although its an interesting question id have to follow up on.
One of the config files will be smokecurrent_config thats the smoke config file. The other one will be the build config file. The last will be a batch file.
| [reply] |
You're right anonymonk, thanks. And, when I re-read the instructions again from the beginning, right there, just 1 paragraph above is:
This will ask you a bunch of questions, for most of them you want to use the defaults. About the only ones you will need to hand edit will be the location of the build directory and the email addresses you want to CC your smoke reports to. For perl-current I use D:\smoke\perl-current once this is done you will find that you have three files in your run directory, one is a build config file, the other is a smoke config file and the last is a batchfile. Once all of this is done in order to run a smoke you simply execute this batch file.
All the info I require is right there. Except, you don't read this type of instructions as a linear flow from top to bottom. You read a bit and do a bit. You read a bit and do a bit. And in between, you do other things. And when you return, you scan down skipping the bits you've down and look for the next bit to do. So, terminology introduced in one paragraph doesn't survive whatever many other things you have done during the interim.
But here the crux. There are 3 files: smokecurrent.cmd, smokecurrent_config, w32current.cfg. Why introduce 3 "terms": "one is a build config file, the other is a smoke config file and the last is a batchfile" to refer to these files? Why not just use their shorter and unambiguous actual name? Eg.
Oh one thing you might want to do is edit the build config file and make sure that something like:
Oh one thing you might want to do is edit w32current.cfg and make sure that something like:
-DINST_DRV=D: -DINST_TOP=$(INST_DRV)\smoke\inst\current
And this is how good documentation comes into being. Everyone knows that I'm far from being a technical author, but I was lucky enough to work with a few, including one extremely good one for several years, and this is the process. He would act as a complete novice, and ask every "stupid" question possible. Believe me, it's not easy to do if you have any knowledge of the subject at all. It requires you to force yourself to not make any assumptions, and to ignore whatever you do know. It is laborious and tedious. But oh so worth the effort whenit is done correctly.
Can I do that? We'll see :)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
Why not just use their shorter and unambiguous actual name?
Well, two reasons, the most important being I was in a rush (relatively speaking -- i was procrastinating doing something with a deadline at the time) and couldn't be bothered to look up the /actual/ names. (Sorry about that.) But the other reason is that you can actually control the names of the files, by using the -p option with configsmoke. Try doing perldoc lib\configsmoke from the run directory for more options.
Regarding your friend the technical author, i know what you mean. Its hard to document/explain something that you know really well without falling into these types of traps. Review by third parties is always useful.
Anyway, do remember that not a lot of people have set up smoke, and even less on win32, and that the package is a work in progress. Contributing back improved documentation would be very useful. :-)
---
$world=~s/war/peace/g
| [reply]
[d/l] |
