0
votes

I am working at a C application with ncurses for a CLI that uses autotools for build. Besides the actual application, there is a testing framework (cutter) and there are some preprocessor constants that enable or disable some features (for example, there is a constant WINDOW that borders all ncurses windows - useful for managing the window layout).

Of course, some of these constants can be specified manually at compile time (i.e. make) but I'd like to have 2 build targets: debug and release. Also, there is a problem with cutter (configure checks for it, and this is supposed to happen if it's going to be used, but I cannot require a normal user to install cutter to compile). So, I was thinking at the following setup: to create a configure flag that enables tests (disabled by default) and 2 make targets (make creates the release version and make debug, the debug one). Is this workflow correct or there is a better way to do this?

1
Lots of people use a method like this instead of a separate debug/release build. This usually allows a pretty good tradeoff between runtime performance and being able to debug after release. - ldav1s
Well, this isn't as much about the -g flag, as it is for parts of code used in development and debugging of the application (like removing some check to make the testing of the application more easier, borders around windows to see what you're doing ans so on). Those are handled with preprocessor directives #ifdef and #ifndef, being toggled by the presence or absence of a certain symbolic constants. - Paul92
You cannot require a normal user of your product to install cutter, but you absolutely can require a developer to do so. A user should be installing a pre-built binary and will not need to deal with any of this. A rather loose definition of "developer" can include anyone who wants to run 'make check', so it is perfectly reasonable to require that person to install another tool, but it is also pretty easy to simply check if cutter is installed and scale back the tests as necessary (with a warning that says something like "test is incomplete: please install cutter") - William Pursell

1 Answers

1
votes

If it were me, I'd use AC_ARG_WITH to setup where the cutter testing framework resides (e.g. include/library paths) and any related stuff that deals with cutter (e.g. preprocessor flags), and one or more AC_ARG_ENABLE variables (or possibly AC_ARG_WITH) to enable other preprocessor directives. This way you don't have to maintain a debug target.