$BL$>5Bz9-9p"(!!AGE($J=P2q$$(B

2003-03-30 Thread FJT$B$N2q(B
$B!c;v6H$^$l$kJ}$N2q$G$9!#(B
$B!!(B($BF~2q;q3J$O!"(B23$B:P0J>e$GF|K\:_=;$NJ}$G$9!#!K(B
(B
$B!y?75,$4F~2q$5$l$?J}$K$O$"$J$?$N$44uK>$K9g$C$?J}$r(B1$BL>L5NA$G>R2p(B
$B!!$7$^$9!*!JM9JX$G>R2p$7$^$9!#!K(B
(B
$B!yFH<+$N8r:]>pJs;o$rH/9T$7$F$*$j$^$9$N$GB??t$N2q0wMM$+$iA*$Y$k(B
$B!!%7%9%F%`$b$4$6$$$^$9!*(B
(B
$B!y$/$o$7$/$O%[!<%`%Z!<%8$r$4Mw$/[EMAIL PROTECTED](B
(B
$B!y%[!<%`%Z!<%8(Bhttp://www.yy-net.co.jp
$B!!(B
(B
(B
$B!y8r:]$NBh0lJb$r$*R2p$G$J$/!"$4$/<+A3$K$*IU$-9g$$$r4uK>$5$l$F$$$k(B
$B!!J}$K$*$9$9$a$G$9(B

Creating a 'make benchmark'

2003-03-30 Thread Dr. David Kirkby
I have written a numerically intensive program
http://atlc.sourceforge.net/
that runs on multiple CPUs using threads. Also, at a very early stage
of development (apparently works on Linux but certainly not on my
Sun), can run distributed over a network. Compiler options, whether
the program is configured with support for threads, or for distributed
processing, all affect the execution speed. 

I was thinking of adding the ability to benchmark the executables.
i.e. so something like 'make benchmark' to run a set of benchmarks and
report on the time taken. 

Firstly, does using automake in this way seem sensible, or should it
not be done using automake?

Secondly, if it is sensible, how would I do it? Can I add a target
like 'benchmark' and if so how? Clearly any such target would need to
depend on the fact the sources have already been built. I could write
the benchmark as a script. So assuming I can write a script called
'timeme', how would I ensure that 'timeme' gets run if the user types
'make benchmark' ?




-- 
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]




Re: Creating a 'make benchmark'

2003-03-30 Thread Sebastian Huber
On Sunday 30 March 2003 12:57, Dr. David Kirkby wrote:
[...]
 Secondly, if it is sensible, how would I do it? Can I add a target
 like 'benchmark' and if so how? Clearly any such target would need to
 depend on the fact the sources have already been built. I could write
 the benchmark as a script. So assuming I can write a script called
 'timeme', how would I ensure that 'timeme' gets run if the user types
 'make benchmark' ?

Hi,
you can write normal Makefile stuff into the Makefile.am, e.g.

benchmark: all
commands





software build

2003-03-30 Thread Enrico Weigelt

Hi,

I'm currently developing an new build system (TreeBuild).
In contrast to existing ones, here the software is described
in an abstract tree structure, instead of an collection of 
build rules.

As an programmer you dont have to cope with the 
compilation process anylonger. You simply write down,
of which parts your software consists and from which
parts others are generated from.

An TreeBuild project contanis an tree of nodes, i.e.
target files (executables, libraries, manpages, ...),
sources (.c, .a, ...), imports (library references), ...
Once an software structure is written down in this 
abstract notation and follows some rules implied by this, 
automatic processings, like compilation, installation, 
removal, dependency-  compatibility-checks can
be done automatically quite easy.

I'd like to invite you to this project.

cu

-- 
Enrico Weigelt, ceo
metux ITS - http://www.metux.de/
[EMAIL PROTECTED]




Re: software build

2003-03-30 Thread Jon Cast
Enrico Weigelt [EMAIL PROTECTED] wrote:
snip description of make 
I hate to break it to you, but this has been done.  It's called make.

Jon Cast




Re: software build

2003-03-30 Thread Thien-Thi Nguyen
Enrico Weigelt [EMAIL PROTECTED] writes:

   I'd like to invite you to this project.

how do you handle cycles in the tree?
how do you handle multiple roots?
how do you handle transient relations?

thi




Re: Can I force 'make install' to depend on 'make test'?

2003-03-30 Thread Dr. David Kirkby
Guido Draheim wrote:
 
 install-data-local : check
 
 That's the answer. In reality I have a last line in the configure.ac
 that says echo '#' make  make check  make install - it does
 remind a casual install-from-source guy to do a make check before
 going to make install. 't works pretty well, since many do a simple
 mousing copy-n-paste of that line in the terminal. It makes that
 `make check` also optional, possibly reducing time for your own
 development cycles with the same source tree (but perhaps you current
 `make check` is quick enough to be run always). Instead I have a
 rpm spec along that uses `make check` always - the rpm build is also
 a great way to check that off-develdir builds will succeed as well.
 
 have fun, guido


Thanks a lot for your advice. To date I have never used a configure.ac
file, only configure.in, but I will look at configure.ac too, as I
like your idea of reminding the user to run 'make check'.

After thinking about it a lot more, with most people on the mailing
list suggesting i should distribute the bitmaps, I decided to
distribute them, rather than build them, so there is no need to force
'make install' to be dependant on 'make check'.

Doing the above increases the package size from about 1.5 to 2.5 Mb
due to the extra bitmaps, but means that once uncompressed, the source
tree is now 190 Mb, which is considerably larger than the 5 or so Mb
before. Since the bitmaps are quite simple (see a few examples at 
http://atlc.sourceforge.net/examples.html
they compress very well, with about a 75:1 compression ratio. Still,
if the user was to do a 'make check' they would have been built
anyway, so the disk space is needed at some point. 

I've now configured 'make check' to build the bitmaps but delete them
as soon as they are confirmed to have the correct checksum. So all the
bitmaps get distributed with the package *and* all the bitmap get
built, but the built versions are quickly deleted as soon as their
checksums are confirmed to be okay. Hence the maximum disk space
needed at any one time is probably about 210 Mb or so. 

The 'make check' is quite slow, so not running it is quite attractive. 


 
 Dr. David Kirkby schrieb:
  Ronald Landheer-Cieslak wrote:
 
 Though I really don't think it's a good idea, have you tried just adding
 install : check to your Makefile.am?
 
 
 
  No, I had not, I might try that - but see below.
 
 
 Anyways, the reason I don't think it's a good idea is that it will break
 cross-compiling, as your test programs will probably not run on the build
 host in that case..
 
 
  Can you suggest a better way? I'm open to suggestions, as I'm not convinced my 
  current method is optimal at all. I had not even considered cross-compilation 
  issues.
 
  In fact, I would *much appreciate* any suggestions for a better method(s). I'm 
  sure what I am trying to do is not the best way, but don't know of a better one.
 
  Basically I will have several source (.c) files that will create 10 platform 
  dependant binary files (executables). All except one of these 10 binary files are 
  designed to quickly produce bitmaps of simple shapes. (i.e. a circle inside a 
  rectangle, a rectangle insider a circle ...)
 
  Next I want to check the 9 binaries are indeed producing the correct bitmaps, so I 
  check the md5 checksum of the bitmaps produced by the 9 binaries. So a test is 
  basically like this (must simplified)
 
  create_bitmap_for_rect_in_rect foo.bmp
  MD5SUM=`md5 foo.bmp`
  if [ $MD5SUM != bdfb21053d9af7302bb587b1b89c113a ] ; then
exit 1
  else
exit 0
  fi
 
  If the md5 checksum of the bitmaps agree with what I expect, I can assume the 9 
  binaries are functioning properly.
 
  After creating the bitmaps with these 9 executables, another program (the 10th 
  binary, called 'atlc') will run a long cpu intensive numerical simulation based on 
  the contents of each bitmap. The output of 'atlc' consists of 6 further bitamps 
  and a text file.
 
  I was expecting for the output from 10th binary (atlc) to be useful it two ways.
 
  1) I can check the checkum of the output files, confirming atlc works okay.
  2) I can install some of the files produced by atlc, for the purpose of examples.
 
  Hence my dilemma. It seems sensible to me that 'make install' requires that 'make 
  check' has already been run, but I'm open to suggestions of how to be structure 
  this.
 
  Should the tests just create files, check their checksum, then remove the files? 
  Or is it better to leave the files around, so they can be installed as examples? 
  Since I want to install these as examples and generating them is time consuming, 
  it seems sensible to do it only once.
 
  Any help appreciated.
 

-- 
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]