According to [EMAIL PROTECTED]: > > Why, at this late stage in the game, are people deleting files without > > removing the references to them in the Makefiles? Is nobody even testing > > the changes they commit? I'd like to test the ones I've committed, > > and hopefully start porting over some of the other fixes from the 3.1.4 > > code, but I can't even get a clean build, and I'm forever frustrated > > with new errors popping up faster than I can stomp down the old ones. > > I've wasted almost 3 hours on this stuff, and I don't feel I'm any closer > > to even being able to start porting 3.1.4 fixes to 3.2. Given that > > this is my last work day before the University closes for the Holidays, > > I doubt I'll be able to get anything done on this. I'll turn my efforts > > to more productive persuits. > > Sorry for this, > > Actually the files HAVE been removed from the Makefile.am but I didn't > commit the Makefile.in. If you rerun configure it should work for you. > I'm going to commit the Makefile.in right now. > > And yes I DID test the changes I commited... several times, I even > wrote extra tests to check if everything ran ok, and they passed. I appreciate all the work and testing that you're doing, but can I ask that you be more careful about the order and completeness of the files you commit to CVS? The whole automake situation was discussed at length many months ago, and it was decided then that because not everyone has an up-to-date version of automake installed, the compilation of ht://Dig should not be dependent on automake - that means you shouldn't commit changes to a Makefile.am without committing the corresponding changes to Makefile.in. Also, you should not remove any source files from the CVS tree until you've purged all dependencies from the tree. Similarly, you shouldn't add any new dependencies to the tree until you've added the files which are depended upon. I'm trying to build RPMs from a clean snapshot of the CVS tree, and every time I run into a new error like this, I have to start over from scratch. It's a tedious process if I can't count on a cleanly buildable source tree, because each time I have to put together a patch to fix the error and rebuild the RPM. It may not sound like the best way to do things, but I'm kind of committed to working on the RPMs, and I'd rather have RPMs for testing purposes because they're more easily installed and removed from the test systems. If I can get a clean build, it'll be a lot easier to test small, incremental changes to a few programs without starting over from scratch each time. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 ------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to [EMAIL PROTECTED] You will receive a message to confirm this.
