Should the .t3m files act more like build files?

First, a slight rant: I don’t like that Workbench so mangles your makefile that you can’t use it outside of the tool again. Workbench removes the -o, -Fo, -Fy, -lib and -source settings. It also removes the -D macro preprocessor information. I realize that Workbench puts these in its own UI-friendly format but this is not good practice for a “programmer’s power tool.” The build file – even if TADS doesn’t call it a build file – should always be usable even when not used as part of the IDE.

I do notice that in the Workbench I can have my debug image file go to build\debug and my release image file go to build\release. Of course what’s happening is that behind the scenes, Workbench customizes the .t3m file. What I don’t see is how I can do that with t3make at the command line without creating two build files. Ideally you’d have something like:

-ro build\release\MyGame.t3
-do build\debug\MyGame_dbg.t3

Here I would have “release output” and “debug output” as options. Which one gets written to depends on whether a -d (debug) flag is set in the build file or passed in as a command line argument.

I realize the documentation says that the .t3m file is not a build file. But, in fact, it really sort of is, at least in terms of how you would use similar such project files with Ant. It’s a file that’s telling the system how to build the project. The fact that a .t3m doesn’t have archetypes like Maven or tasks like Ant does not make it any less of a build file of sorts. The .t3m file goes some of the way but not all of the way, and I think that’s to it’s detriment.

I’m guessing I might be in the minority on that. But, I’ll say it again, since TADS is being touted as a programmer power tool, I don’t think it’s unrealistic for developers (as opposed to just programmers) to use the tool somewhat in line with the many other development tools out there.

Even with my whining lately, I still think TADS is an awesome language.

Probably your best bet is to open a feature request ticket in the TADS Bug Database.

On the infrequent occasions I use Workbench, I find this behavior somewhat of a nuisance, albeit a minor one - it’s easy to revert to the previous Makefile from source control.

But I don’t see the issue you mention, either. Here’s my pre-Workbench Makefile:

-o practice.t3
-Fy obj
-Fo obj

-lib system
#-lib webui
#-lib adv3/adv3web
-lib adv3/adv3
#-source tadsnet
-source practice

And here is the post-Workbench version:


TADS 3 makefile

Warning: this file was mechanically generated. You may edit this file

manually, but your changes might be modified or discarded when

you load this file into a TADS development tool. The TADS tools

generally retain the comment at the start of the file and the

comment marked “##sources” below, but other comments might be

discarded, the formatting might be changed, and some option

settings might be modified.

-o practice.t3
-Fy obj
-Fo obj

-lib system
-lib adv3/adv3
-source practice

The following is machine-generated - DO NOT EDIT

build:ext resfile cnt:I:0
build:defaults set:I:1
watch win:pos:R:312,786,596,902
watch win:vis:I:0
log win vis::I:1
log win pos::R:461,206,1577,1098
watch win:sep xpos 0:I:142
watch win:sep xpos 1:I:142
watch win:sep xpos 2:I:142
watch win:sep xpos 3:I:142
build:installer options:S:0:name=Makefile_dbg
build:installer options:S:1:savext=Makefile_dbg
search:start at top:I:0
proj search:exact case:I:0
*58 src win pos:C:\Projects\Dropbox\Coding\practice\practice.t:R:25,25,841,637
auto-script:quit sequences:S:0:[<]line[>]q(uit)?
auto-script:quit sequences:S:1:[<]line[>]y.
docking config::S:0:CL
docking config::S:1:CB
docking config::S:2:CL
docking config::S:3:W2,170,270,2,760,302,910,D,L,project win
docking config::S:4:W2,170,150,175,760,345,910,D,L,script win
docking config::S:5:W-1,270,170,304,760,604,910,D,B,watch win
docking config::S:6:W-1,270,170,2,760,302,910,D,B,locals win
docking config::S:7:W-1,170,170,-131,88,1052,647,M,B,docsearch win
docking config::S:8:W-1,170,170,-247,64,936,623,M,R,help win
docking config::S:9:W-1,170,170,-382,71,801,630,M,R,stack win
docking config::S:10:W-1,170,170,25,25,1113,584,M,R,log win
locals win:pos:R:10,786,294,902
locals win:vis:I:0
main win max::I:0
proj search:collapse spaces:I:0
search:exact case:I:0
mdi win list::S:0::log
mdi win list::S:1:C:\Projects\Dropbox\Coding\practice\practice.t
main win pos::R:281,75,1587,1131
proj search:whole word:I:0
help win vis::I:0
docsearch win vis::I:0
script win:pos:R:291,968,452,1098
script win:vis:I:1
hist win vis::I:0
proj search:regex:I:0
locals win:sep xpos 0:I:142
locals win:sep xpos 1:I:142
search:whole word:I:0
mdi tab order::S:0:1,0
main win mdi max::I:1
auto-script:default quit sequences set:I:1
mdi win title::S:0:
mdi win title::S:1:C:\Projects\Dropbox\Coding\practice\practice.t
build:installer prog:S:0:Makefile_dbg_Setup.exe
project win:pos:R:291,203,452,942
project win:vis:I:1
filesearch win vis::I:0
stack win vis::I:0

It kept all my active build options in place, though I lost some commented lines.

Interesting. I was clearly doing something wrong or I got unlucky in terms of timing. It looks like my Git setup caught the file in transition or something. You are correct: the .t3m file does appear to be fully in place if I don’t do my Git workflow as part of the process. More than likely I somehow caught the file as it was being reformatted.