Or not. See the debate on use of special files in
my previous message.
Unless a file is meaningful such as actual tests rather
than a "test harness", it is better served being a project
target and not pollute the folder.
Consider this test_src.ijs copied from addon to addon
===========================================================
NB. Builds and loads project, then
NB. loads test_{addonname}.ijs located in the same folder as this script.
buildproject_jproject_ ''
loadtarget_jproject_ ''
TestPath=. getpath_j_ TESTFILE_jproject_
TestFile=.'test_',(#...@getpath_j_ }. ]) TARGETFILE_jproject_
cocurrent 'base'
load TestPath,TestFile
===========================================================
It carries not meaning. Some of the steps refer to dependencies
on other targets whose execution should be conditional, other
could be delegated to actions which "know" how to treat things
such as finding a test file and resolving paths.
Here's a few definitions, which are similar with Make or Ant.
Project is unique per folder contains properties and targets.
Target is THE callable build entity, it consists of properties
and actions, has dependencies to other targets, invoked conditionally
before the current one.
Actions are types of target steps which take parameters and use
project and target properties. There is an action to invoke
a target at any step.
The use of properties make them observable and support such
features as conditional execution using time stamps of
Source and Result files.
In its simplest form, targets are explicit verbs in the project
and actions are verb sentences using API verbs.
Consider the following project fragment
===========================================================
target_build=: 3 : 0
assemble''
)
build_result=: 'main.ijs'
build_sources=: 0 : 0
one.ijs
two.ijs
)
target_test=: 3 : 0
test'test.ijs'
)
test_depends=: 'build'
test_default=: 1
target_run=: 3 : 0
load'main.ijs'
main''
)
run_depends=: 'build'
target_debug=: 3 : 0
start_debugging''
invoke_target'run'
)
debug_depends=: 'build'
===========================================================
The attributed programing idea is used earlier in the
general/unittest addon.
> From: bill lam <[email protected]>
>
> Yes your are correct. I guess it would sufficient to provide menu
> item or keyboard shortcut to run the following project specific
> scripts.
>
> 1. run the 'load.ijs' script which will load all project script
> 2. run the 'run.ijs' script
> 3. run the 'test.ijs' script
>
> Having these (or similar) file names fixed so that they need not be
> explicitly mentioned inside .proj file.
>
>
> On Fri, 16 Oct 2009, Sherlock Ric wrote:
> > My understanding (may be wrong) of the Wiki proposal is that the pre-build
> hook will not exist in the new PM, but that the buildfile will be the
> equivalent
> of the current post-build script. (i.e. the creation of the targetfile is the
> "build" step).
> >
> > As Chris says, trying to provide lots of flexibility starts to make a GUI
> quite complex, but isn't necessarily hard in a J script.
> >
> > Perhaps the preload, postload functionality can be provided by the proposed
> testfile. Rather than a whole lot of GUI options one solution might be to
> provide the user with a testfile template that they can edit.
> > e.g.
> >
> > NB.===== testfile template ========
> > NB. Add any pre-load processing here
> >
> > load targetfile
> > NB. Add any post-load processing here
> >
> > NB. call any test scripts here
> > load ,&'_test.ijs'_4}. Targetfile NB. default name for test script
> >
> > NB. Add any post-test processing here
> > NB.================================
> >
> > Alternatively a bunch of templates could be presented for the user to
> > choose
> from, or to a custom template could be built on the fly based on the user's
> answers to a dialog or wizard.
> >
> > This solution could potentially also cater for Anssi's suggestion for a
> > "Clear
> & Load" button.
> >
> > [---=| TOFU protection by t-prot: 19 lines snipped |=---]
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
