Re^10: 5.10 imminent?

[demerphq]

Ok, first off, no pretty much everything youve said here is not correct. Sorry. Also, if you are going to smoke then get used to using rsync. Rsync would have been only marginally slower than wget to complete if you had done it properly and that would be a one time payment, wheras the cost of fetching from the snapshots will be fixed every time. Anyway, now that you have a snapshot rsyncing should be extremely easy. Just unpack the snapshot into a directory and rsync from there. Normally when i rsync its a matter of 60 seconds or less to get an updated version. Less if nothing has changed. (BTW, the 'z' option means to gzip any data being tranferred)

Note also you dont want to use -avz on a windows box, use -rtvz instead (or omit the 'v' to get less verbiage), and when you are first doing things DO include the --dryrun option and DO include --delete option, once you are happy things are working remove the --dryrun option. Without the delete option old files that are no longer used will not be removed.

Next, create a directory for your smoking. I use the following structure:

D:\smoke
D:\smoke\src
D:\smoke\run
#and hypothetically
D:\smoke\perl-current
D:\smoke\perl-5.8.x

I use this structure btw because the run directory will end up with various autogenerated batch files in it. And since I had to do some tweaking to get test smoke set up on Win32 I wanted all of its install and autogenerated batch files in a seperate path from the perl sources so i could do easy searches on the tree without also searching the perl sources.

CD into the src directory and run the following (note the dot at the end of the command).

rsync --delete -rtz source.Test-Smoke.org::ts-current .

Then do the normal mantra:

perl Makefile.PL && nmake && nmake test && nmake install

When the Makefile asks you where you want to install the smoke libraries tell it D:\smoke\run\lib. Once this is done you will have installed the latest version of Test::Smoke into that directory.

Next cd into D:\smoke\run and execute the batchfile via relative referencing accordingly:

lib\configsmoke

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.

And thats about it actually.

You may want to 'tail -f smokecurrent.log' from the run directory to whatch what is going on, or you can do a grep Configuration: smokecurrent.log and see how many different configurations have been completed. Out of the box a smoke run will build 8 different configurations.

Oh one thing you might want to do is edit the build config file and make sure that something like:

-DINST_DRV=D: -DINST_TOP=$(INST_DRV)\smoke\inst\current

Is specified, nothing will actually be installed in this location, and in fact the location should NOT exist, but it will help prevent the possibility of a header mismatch if you have a perl installed in the standard location. I actually got a patch applied recently that fixed the only example of this bug, but its better to be on the safe side.

Update: There is one annoyance that you should address, and that is that there are weird permission issues currently with some of the files in the bundle. Instead of letting smoke rsync directly I have it execute the following batch file:

rsync %*
echo y|cacls D:\smoke\perl-current\*.* /T /C /P Everyone:F >nul
attrib -r /s /d D:\smoke\perl-current\*.* >nul

This will ensure that all the files are writable and have the correct permissions after the rsync. Its possible that the cacls call is superfluous with '-rtz' (versus '-az') but i keep it in there anyway.

[BrowserUk]

Ok, first off, no pretty much everything youve said here is not correct. Sorry.

No need for apologies, I pretty much knew it would be when I posted it, hence the '?'s. But, with greatest of respect and thanks for your having posted this 'blow by blow on win32', without having done any further googles looking for specific keyphrases from the above, almost nothing of what you have posted relates to anything I have seen in any of the many, many online documents I have scanned looking for answers.

So the question is, how could I (or any other potential Win32 smoketest neophyte), have discovered this information other than by asking? You are now a well seasoned perl source diver/builder/tester/developer, but it has taken you something like 2 years of your free time to reach you current level of knowledge? I assume that you have acquired the knowledge that allowed you to arrive at the above, over some considerable subset of that period. And maybe with some assistance from your forbears and peers on the p5p lists?

Anyway, my greatest thanks for your having taken the time to write up the above. I will attempt to work my way through it this evening and record my progress and experiences. Assuming that I am able to achieve the desired result, I will write up a full step by step of the process and post it here in a new thread for others to see and perhaps use.

[demerphq]

Actually I only got smoke up and running over the last week. There were some issues with the smoke framework under win32 and I worked with Abe to get them resolved. Theres no question that getting smoking running on win32 is/was non-trivial and underdocumented. Since there are only two or three people doing it there hasnt been a lot of testing. However I now smoke daily on win32 so ill be keeping an eye on the process. And Abe is quite responsive to issues with smoke so if issues come up they are addressed fairly quickly.

I agree with you btw, its not an easy process to do without somebody to hold your hand. It would be a real benefit to the community if you converted my quick review here into a proper pod document for doing smokes on win32. In fact the smoke documentation could do with a HOWTO or something that runs through the full process. Currently most of the explanations are scattered through various files and its not so clear how to procede.

Please note I updated the first paragraph of my post, and added one to the bottom. If any issues come up with the process why not email me about it and ill see what i can do to help you out.

[BrowserUk]

Before I go any further, is the following expected when testing Test::Smoke? Or should I try and resolve these issues before going further?

<Reveal this spoiler or all in this thread>

Update:Looking into this it's probably because I have -w enabled on my perl alias?

[BrowserUk]

Oh one thing you might want to do is edit the build config file and make sure that something like:

Could you clarify what/where the "build config file" is?

[demerphq]

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.

[BrowserUk]

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 :)