<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I think you have multiple obvious choices, that you are aware of, that you don't think you want:<BR> <BR> <BR>1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code<BR> <BR> <BR>1b) or just live it with it all being present all the time<BR> <BR> <BR>2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would..<BR> <BR> <BR>"Hey, look", I've worked with a few build systems. Mostly NT Build.<BR> <BR> <BR>There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. <BR>m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language.<BR> <BR> <BR>(NT Build is publically available in the Windows DDK, at least until recent versions.)<BR> <BR> <BR>They both limit, mostly, source files to be in leaf directories.<BR>You can't reach around and build random source from random other places.<BR>Unless you turn it into a library or .obj.<BR> <BR> <BR>NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost.<BR> <BR> <BR>In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems..<BR> <BR> <BR>Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :)<BR> <BR>> with its own m3makefile and its own symbolic link to a common src directory.<br><BR>And how are you going to check that into CVS and sync and build it on file systems without symlinks?<BR>Not portable.<BR> <BR> - Jay<br><br> <BR><div>> Date: Sat, 6 Jul 2013 22:11:18 -0400<br>> From: hendrik@topoi.pooq.com<br>> To: m3devel@elegosoft.com<br>> Subject: [M3devel] Multiple executables from the same source<br>> <br>> I'm writiing and debugging a bunch of interfaces and modules.<br>> They are all supposed to fit together into one happy executable.<br>> <br>> But of course, until I've finished debugging them<br>> they fit together into one unhappy executable.<br>> To test them properly I'd like to write a series of unit tests.<br>> To run these tests I will need to make further executables,<br>> each consisting of a test modules and several of the modules under test.<br>> <br>> Now with the usual structure of a Modula 3 workspace,<br>> there is one m3makefile and a src directory, and it makes one executable,<br>> not many,<br>> and it doesn't really give me a choice of which executable I want.<br>> <br>> In the old days of C code and Makefiles, I could have multiple targets<br>> each one being built with its own cc command<br>> with its own list of source files names.<br>> <br>> Is there anything comparable for Modula 3?<br>> <br>> The best I've come up sith so far is to have a number of directories,<br>> one for each test case,<br>> with its own m3makefile and its own symbolic link to a common src directory.<br>> <br>> Is there something better?<br>> <br>> I'm not really interested in having all the test code<br>> be part of the final application.<br>> <br>> For one thing,<br>> I'd like to be able to test multiple implementations of a single interface,<br>> such as a reference implementation and an efficient one,<br>> so that I can compare the output and complain about the differences.<br>> <br>> -- hendrik<br></div> </div></body>
</html>