From minc-development@bic.mni.mcgill.ca Fri Apr 1 06:12:03 2005 From: minc-development@bic.mni.mcgill.ca (Steve M. Robbins) Date: Fri, 01 Apr 2005 01:12:03 -0500 Subject: [MINC-development] AX_CHECK_GL and friends Message-ID: <20050401061203.GC5311@nyongwa.montreal.qc.ca> Hi, I just updated my CVS tree for Display and found it failed to link. ... ten minutes later I discovered the cause: I don't have definitions of several autoconf macros: ACX_PTHREAD AX_CHECK_GL AX_CHECK_GLU AX_CHECK_GLUT AX_LANG_COMPILER_MS I found them in the autoconf macro archive and can now build Display. However, it's probably a good idea to put all non-standard macro definitions into mni-acmacros (a.k.a. directory m4), and also to distribute said macros in the tarball. What d'all think? If you agree, I can do the CVS monkeywork. -Steve From minc-development@bic.mni.mcgill.ca Fri Apr 1 07:11:09 2005 From: minc-development@bic.mni.mcgill.ca (Steve M. Robbins) Date: Fri, 01 Apr 2005 02:11:09 -0500 Subject: [MINC-development] AX_CHECK_GL and friends In-Reply-To: <20050401061203.GC5311@nyongwa.montreal.qc.ca> References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> Message-ID: <20050401071109.GE5311@nyongwa.montreal.qc.ca> On Fri, Apr 01, 2005 at 01:12:03AM -0500, Steve M. Robbins wrote: > I found [missing macros] in the autoconf macro archive and can now > build Display. Murphy strikes again: I wrote that before the build actually finished and then discovered that Display wouldn't link. :-( The PPM library wasn't linked in (needed by bicpl). The root cause is that AM_PROG_LIBTOOL was removed from configure.in. The check-in comment associated with this change is: revision 1.14 date: 2005/02/03 09:30:54; author: rotor; state: Exp; lines: +12 -16 * updates for OSX build with native OpenGL * Added epm-header.in Was removing libtool necessary to build under OSX? My libtool (version 1.5.6) appears to support Apple's darwin. The *advantage* of linking against bicpl using libtool is that libbicpl.la lists all the required libraries: # Libraries that this one depends upon. dependency_libs=' -lppm /usr/lib/libvolume_io.la /usr/lib/libminc.la -lnetcdf -lm' and libtool picks these up when composing the link line for Display. The list of dependencies of bicpl is not static -- it depends on the configuration options when bicpl is built, notably options --with-image-ppm and --with-image-sgi. So the dependencies cannot be hard coded in the Display build system. You could conceivably try to auto-detect them, but since libtool exists to save you from this why not use it? -Steve From Andrew Janke Fri Apr 1 12:22:32 2005 From: Andrew Janke (Andrew Janke) Date: Fri, 1 Apr 2005 22:22:32 +1000 Subject: [MINC-development] AX_CHECK_GL and friends In-Reply-To: <20050401071109.GE5311@nyongwa.montreal.qc.ca> References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050401071109.GE5311@nyongwa.montreal.qc.ca> Message-ID: On Apr 1, 2005 5:11 PM, Steve M. Robbins wrote: > > > I found [missing macros] in the autoconf macro archive and can now > > build Display. Given that these macros are in the acmacros package/distribution, I had figured it best to not include them in case they were updated or the likes. Would you still reccomend including a static version of them with Display/Register/etc? Myself I'd prefer to use as much of what is "out there" as opposed to rolling our own all the time? > Murphy strikes again: I wrote that before the build actually finished > and then discovered that Display wouldn't link. :-( > > The PPM library wasn't linked in (needed by bicpl). The root cause is > that AM_PROG_LIBTOOL was removed from configure.in. The check-in > comment associated with this change is: > > revision 1.14 > date: 2005/02/03 09:30:54; author: rotor; state: Exp; lines: +12 -16 > * updates for OSX build with native OpenGL > * Added epm-header.in > > Was removing libtool necessary to build under OSX? My libtool > (version 1.5.6) appears to support Apple's darwin. Likely not. But then, I don't remember purposely removing it. The bicpl thing was something that I need to fix. none of the binary releases specify any graphic library, as such things like ray_trace have no binary build, and the binary versions of register/Display won't be able to export images. I had heard on the grapevine that bert had a imagemagick version of bicpl and have been eagerly awaiting that instead. Reason being I haven't (yet) been able to build bicpl using ppm on the mac yet. :( > The *advantage* of linking against bicpl using libtool is that > libbicpl.la lists all the required libraries: > > # Libraries that this one depends upon. > dependency_libs=' -lppm /usr/lib/libvolume_io.la /usr/lib/libminc.la -lnetcdf -lm' > > and libtool picks these up when composing the link line for Display. > The list of dependencies of bicpl is not static -- it depends on the > configuration options when bicpl is built, notably options > --with-image-ppm and --with-image-sgi. So the dependencies cannot > be hard coded in the Display build system. You could conceivably > try to auto-detect them, but since libtool exists to save you > from this why not use it? Given my rudimentary understanding of the complete autoconf/make system (I know what I need to know and a little more in order to get me into trouble), I bow in deference to you with respects to things like this :) I suspect there will be more subtle changes soon to Display/register for the upcoming binary mingw/cygwin builds (soon, soon). So, do you prefer to add libtool back in or shall I? And if you do, can you test the build on OSX too please? a From Andrew Janke Fri Apr 1 12:27:46 2005 From: Andrew Janke (Andrew Janke) Date: Fri, 1 Apr 2005 22:27:46 +1000 Subject: [MINC-development] AX_CHECK_GL and friends In-Reply-To: <20050401071109.GE5311@nyongwa.montreal.qc.ca> References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050401071109.GE5311@nyongwa.montreal.qc.ca> Message-ID: > The *advantage* of linking against bicpl using libtool is that > libbicpl.la lists all the required libraries: > > # Libraries that this one depends upon. > dependency_libs=' -lppm /usr/lib/libvolume_io.la /usr/lib/libminc.la -lnetcdf -lm' Ah! forgot too.. Whilst on the subject of libtool, do you happen to know of any way whereby you can force libtool to use relative paths (or facillitate prefixed installs?) Reason being is that when building binary packages, Ibuild in a quarrantined directory so that I can check dependencies. ie: ./configure --prefix=/tmp/epm-build/target/minc-${vers} \ --with-build-path=/tmp/epm-build/target/comb Then I build the binry package from the prefix before synching the result to the comb directory for building against (could use stow here, but haven't got to it). Problem is, the .la file paths are now all way of course. I guss the other thing I could do is chroot for the binary build, but chroot/fakeroot doesn't exist on all platforms. :( Thoughts? a From minc-development@bic.mni.mcgill.ca Sat Apr 2 07:33:55 2005 From: minc-development@bic.mni.mcgill.ca (Steve M. Robbins) Date: Sat, 02 Apr 2005 02:33:55 -0500 Subject: [MINC-development] AX_CHECK_GL and friends In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050401071109.GE5311@nyongwa.montreal.qc.ca> Message-ID: <20050402073355.GM5311@nyongwa.montreal.qc.ca> On Fri, Apr 01, 2005 at 10:22:32PM +1000, Andrew Janke wrote: > On Apr 1, 2005 5:11 PM, Steve M. Robbins wrote: > > > > > I found [missing macros] in the autoconf macro archive and can now > > > build Display. > > Given that these macros are in the acmacros package/distribution, I > had figured it best to not include them in case they were updated or > the likes. I hadn't realized that someone has packaged the autoconf archive. Oh, wait! ... Actually I guess I did know, since I see that it's installed here (Debian package autoconf-archive). > Would you still reccomend including a static version of them with > Display/Register/etc? Myself I'd prefer to use as much of what is > "out there" as opposed to rolling our own all the time? I agree wholeheartedly to use existing macros. But how do you make it easy for developers? If it were a simple matter of "install package autoconf-archive" before running aclocal (or autogen.sh), I could live with that. This should be documented in BIG BOLD letters in INSTALL.display because if you do NOT have the appropriate macro files the configure script can still be generated, apparently "successful", but the script is, in fact, broken and Display will fail to link. However, on my Debian system "aclocal" doesn't search the autoconf-archive macros by default, so autogen.sh is broken. I would have to run aclocal by hand with an extra "-I" option. (Is that what you did?) Alternatively, I could first copy or link the macro files into the m4 directory. But then why not do this once and put it into CVS? Macros smr_WITH_BUILD_PATH.m4 and mni_cxx_have_koenig_lookup.m4, to name two, are already part of the autoconf archive and also in our CVS tree. The second reason to put them into CVS is that we then have control over what appears in the the source distribution. Imagine that you've tweaked the configure script to build on OSX while using the newest AX_CHECK_GL. But suppose I have an older autoconf-archive installed here and generate the source tarball from a broken AX_CHECK_GL macro. You'll tear your hair out tracking down these bugs. Better to put the macros in CVS to ensure we're all working from the same sources. > I had heard on the grapevine that bert had a imagemagick version of > bicpl and have been eagerly awaiting that instead. Reason being I > haven't (yet) been able to build bicpl using ppm on the mac yet. :( Odd; I would have expected PPM to build easily on the mac. What's the problem? But if your bicpl doesn't link with an image library, at least this explains why you didn't encounter the link problem with Display. > I suspect there will be more subtle changes soon to Display/register > for the upcoming binary mingw/cygwin builds (soon, soon). So, do you > prefer to add libtool back in or shall I? And if you do, can you test > the build on OSX too please? I will put it back. But I don't have access to an OSX machine, so I can't test it. Sorry. -Steve From minc-development@bic.mni.mcgill.ca Sat Apr 2 08:00:11 2005 From: minc-development@bic.mni.mcgill.ca (Steve M. Robbins) Date: Sat, 02 Apr 2005 03:00:11 -0500 Subject: [MINC-development] AX_CHECK_GL and friends In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050401071109.GE5311@nyongwa.montreal.qc.ca> Message-ID: <20050402080011.GN5311@nyongwa.montreal.qc.ca> On Fri, Apr 01, 2005 at 10:27:46PM +1000, Andrew Janke wrote: > Whilst on the subject of libtool, do you happen to know of any way > whereby you can force libtool to use relative paths (or facillitate > prefixed installs?) > > Reason being is that when building binary packages, Ibuild in a > quarrantined directory so that I can check dependencies. ie: > > ./configure --prefix=/tmp/epm-build/target/minc-${vers} \ > --with-build-path=/tmp/epm-build/target/comb > > Then I build the binry package from the prefix before synching the > result to the comb directory for building against (could use stow > here, but haven't got to it). Problem is, the .la file paths are now > all way of course. Where is the package going to be installed? Let's say it should ultimately appear in /minc-${vers}/{bin,lib,etc}. Then you must configure and build using --prefix=/minc-${vers}, ditto for --with-build-path. I don't know of any way around this short of sneaky, brittle sed-tricks on the .la file. It sounds like you are building up the quarantine one package at a time (MINC, BICPL, Display, ...) but you want to make a binary of each package separately? The solution is easy for packages that use automake: they always support DESTDIR. What you do is configure with the desired prefix, /minc-${vers}, but install into a staging directory, say /tmp/staging/minc-${vers}. ./configure --prefix=/minc-${vers} --with-build-path=/minc-${vers} make all test make install DESTDIR=/tmp/staging The configuration and make will build .la files that refer to /minc-${vers}, but the "make install" line will install into directories rooted at $DESTDIR/$prefix; i.e. into /tmp/staging/minc-${vers}/{bin,lib,etc}. Then you simply build the binary package from $DESTDIR. This is a standard trick for Debian packaging (presumably others', too). For your quarantine you'd also want to do a regular "make install" so that it appears in /minc-${vers}, available for the next package on the list. Or install the newly-created package. > I guss the other thing I could do is chroot for > the binary build, but chroot/fakeroot doesn't exist on all platforms. Worse: you probably don't have a compiler and other build tools in /tmp/epm-build/target/comb, so a chroot build will fail for this reason. -Steve From Andrew Janke Thu Apr 7 15:27:04 2005 From: Andrew Janke (Andrew Janke) Date: Fri, 8 Apr 2005 00:27:04 +1000 Subject: [MINC-development] glim_image Message-ID: Morning all, I have just checked some changes I have been making to glim_image into CVS. The main change was a re-write of the design file I/O function in glim.c By using volume_io file input routines, this means that you can finally have comments in glim_image input files! (yay!) Could those who have a vested interest in glim_image, please try a build from CVS and see if the results are identical. They should be! or at least were the same for the test runs I did. Thanks -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138 8581 From minc-development@bic.mni.mcgill.ca Wed Apr 13 17:42:08 2005 From: minc-development@bic.mni.mcgill.ca (Richard Boyes) Date: Wed, 13 Apr 2005 17:42:08 +0100 Subject: [MINC-development] nu_correct & auto_mask In-Reply-To: <20050401061203.GC5311@nyongwa.montreal.qc.ca> References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> Message-ID: Hello everybody, I am interested in using the -auto_mask feature of N3 but I am unsure how to put my scan into the same space as the average_305 scan so that N3 can pick up the fact that its in the same space as the average_305_mask_1mm.mnc.gz mask. I have registered my scan to the average_305.mnc to give me my_scan_r305, but am not sure how to give it to N3 for processing so that the -auto_mask gets picked up. Do I have to go mincresample -talairach or something ?? Thanks for any help Richard From minc-development@bic.mni.mcgill.ca Fri Apr 15 21:38:47 2005 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 15 Apr 2005 16:38:47 -0400 Subject: [MINC-development] nu_correct & auto_mask In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> Message-ID: <20050415203847.GB7951@sickkids.ca> Dear Richard, N3 checks the xspace:spacetype variable for the word 'talairach'. Using mincresample with the -talairach option should make this work. with regards, John On Wed, Apr 13, 2005 at 05:42:08PM +0100, Richard Boyes wrote: > Hello everybody, > > I am interested in using the -auto_mask feature of N3 but I am > unsure how to put my scan into the same space as the average_305 > scan so that N3 can pick up the fact that its in the same space > as the average_305_mask_1mm.mnc.gz mask. > > I have registered my scan to the average_305.mnc to give me > my_scan_r305, but am not sure how to give it to N3 for > processing so that the -auto_mask gets picked up. > > Do I have to go mincresample -talairach or something ?? > > Thanks for any help > Richard > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Mon Apr 18 08:55:36 2005 From: minc-development@bic.mni.mcgill.ca (Richard Boyes) Date: Mon, 18 Apr 2005 08:55:36 +0100 Subject: [MINC-development] nu_correct & auto_mask In-Reply-To: <20050415203847.GB7951@sickkids.ca> References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050415203847.GB7951@sickkids.ca> Message-ID: Thanks John, Richard On Fri, 15 Apr 2005 16:38:47 -0400, John G. Sled wrote: > > > Dear Richard, > > N3 checks the xspace:spacetype variable for the word 'talairach'. > Using mincresample with the -talairach option should make > this work. > > with regards, > > John > > On Wed, Apr 13, 2005 at 05:42:08PM +0100, Richard Boyes wrote: >> Hello everybody, >> >> I am interested in using the -auto_mask feature of N3 but I am >> unsure how to put my scan into the same space as the average_305 >> scan so that N3 can pick up the fact that its in the same space >> as the average_305_mask_1mm.mnc.gz mask. >> >> I have registered my scan to the average_305.mnc to give me >> my_scan_r305, but am not sure how to give it to N3 for >> processing so that the -auto_mask gets picked up. >> >> Do I have to go mincresample -talairach or something ?? >> >> Thanks for any help >> Richard >> _______________________________________________ >> MINC-development mailing list >> MINC-development@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development