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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

In reply to Re^13: 5.10 imminent? by BrowserUk
in thread 5.10 imminent? by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.