Prompting for information during a build

[Mike Lewis]

I've often thought it would be useful if VFP could prompt the programmer for information while it is running a build. For example, it could ask if you wanted a test or a production version of the application, and bring in the appropriate code depending on the reply.

The conventional way of doing this sort of conditional build would be something like this:

#DEFINE COMPILE_TYPE "Test"
…. 

#IF COMPILE_TYPE == "Test"

* Test code goes here

#ELSE

* Production code goes here

#ENDIF

This is OK. But, whenever you do a build, you have to remember to open the file, check the #DEFINE, edit it if necessary, and save the file. It would be better if you could get VFP to prompt you for the setting during the build.

I thought I might be able to achieve that by using a projecthook, but I couldn't see any simple way of doing that.

Then I realised the #IF directive can take any expression as its operand, and that expression can include VFP functions, such as MESSAGEBOX(). So now I do this:

#IF MESSAGEBOX("Is this a test?", 4) = 6

* Test code goes here

#ELSE

* Production code goes here

#ENDIF

This achieves my goal perfectly.

You could extend the technique by using INPUTBOX() rather than MESSAGEBOX(). That would let you work with a variety of values, each of which could control the build in a more specific way.

Does anyone else here do anything like this? Or have you got some other method of varying the behaviour of a build?

In any case, I hope the above suggestion will be of interest.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

I very rarely have different code for test vs. production. I generally want to test the code that will end up in production. <g> (I know this isn't what you meant.)

On a project of any complexity, though, I'll usually automate the build process. My own build dialog will typically have checkboxes for whether or not to include debug code (and set copyright information and other stuff), and then use BUILD EXE to complete the job.

I've also been known to use some internal-only code not intended for distribution, particularly when tracking some really obscure condition, but rather than a compiler directive I'll test something environmental such as:

If GetEnv("USERDOMAIN")="My Internal Domain"
* or even GetEnv("USER")
* debugging or special condition trapping here.
Endif

That way, no matter how I compile I know my internal-only code won't execute on users' machines.

 

[Mike Lewis]

Dan,

I was only using test vs. production as an example. In practice, I don't often do that.

I use VERSION(2) to check if I'm running in the development environment (which is where I do my "debugging only" stuff). I hadn't thought of using GetEnv("USERDOMAIN"). (Or or even SYS(0)?) It would have the advantage of letting me run the testing code from an EXE.

But I take your more general point: automating the build with a custom form that does BUILD EXE programmatically. Sounds like it might be worth considering.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Yes, in a larger environment testers probably *won't* be running in the IDE so Version(2) would only be useful to the developers. (But that *is* another useful condition to bring to bear!)

On a recent team we had testers who also supported the product so we carefully engineered environments where they could run our latest test builds *or* production, but they were always running exes.

I like automating builds if for no other reason than not having to remember to increment the copyright year in Project Options every December 31st. Or, more succinctly, not forgetting to do it. <g>

 

[Olaf Doschke]

On obvious switch you can also use is _vfp.startmode and some commands only have an effect at designtime anyway, as ASSERT and SET STEP ON, which are disregarded in the exe, ASSERTS can also be turned on and off. A framework I use does a check for a file debug.txt

All these options are not influencing, if code portions are actually compiled into the exe or not, but still are ways to debug at demand.

Are you concerned about exe size, code running unintended or being recompiled?

I found little use for conditional compiling, I rather have some vcxes and prgs excluded in whole via the project manager.

You could always do preprocessing additional to preprocessor directives by a projecthook BeforeBuild event.

Bye, Olaf.

 

[craigber]

You want to automate as much of the process as possible. Ideally, do a build and run tests with every check-in. This is called Continuous Integration (CI). It's a good start. There are free CI servers that you can get to do much of the work. But you should know that industry best practice is moving towards Continuous Delivery, where even the deployment is automated.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

Thanks for all your comments.

It's interesting to hear your ideas about automating the build. These are all valid ideas. But I was really only offering this as a simple way of making decisions at build-time interactively, to avoid having to edit compiler directives.

I've found this idea useful in certain circumstances, and I posted here in the hope that others would too.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[craigber]

You still automate, but have different scenarios. For example, one option is to build for testing. When you kick off that process, it knows how to deal with compiler switches, etc that you need. If you build for release, you kick off a different process that handles those options for you.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog