Wow. Didn't mean to trigger a diatribe with my little question, which you didn't really answer. What I gather from your response is that the build set-up requires you to compile multiple times with dmake to resolve the issue, which is unacceptable in your case because you already have so many compiles to deal with. I get it. I will take your fix suggestion and see what I can do.
I do want to respond to the other issues you mentioned, though: > As I'm building a radiance package I have to rebuild multiple times > because: > + The package includes multiple architecture isaexec versions of the key > executables and the complete compile is done for each. I'm not really familiar with Solaris, but on other systems (like OS X) you can compile in the different architectures in one go. Even that is a pain, so I sympathize. > + I first have to determine which arches, flags and compiler to use. Yes, well, we don't have all the different machines in the world to practice on, and this is an ongoing issue. > + I've had to rebuild the whole package many times for the, ahem, > problems in radiance (not relocatable "define DEFMAPFILE > \"/usr/local/lib/ray/lib/arch.map\"", timegm, the ambient bug, version > still wrong, examples broken by hdr renaming, issuing different source > distributions with the same 4R0 name, etc.) Each change I make requires > a traceable patch and build, hence full package rebuild. One at a time: > not relocatable "define DEFMAPFILE \"/usr/local/lib/ray/lib/arch.map\" I actually didn't know about this because it's in a program that no one (as far as I know) uses anymore, arch2rad. The build for it should probably be disabled, rather than carrying whatever problems it has into the next release. I will do that. > timegm There is a replacement implementation for this GNU extension in src/common/timegm.c, which I assume you found. I shall add this to the COMPAT variable for Solaris. > the ambient bug Could you be more specific? Unless this is the recurring problem with the NFS lock manager, which I didn't think an issue under Solaris. > version still wrong ?? > examples broken by hdr renaming I am sorry about that. If you can point to specific documents that need fixing, I will fix them. One of the big problems with being the only maintainer of a package that has developed and evolved for 20+ years is that there''s a lot of stuff buried in it that I don't think about anymore. > issuing different source distributions with the same 4R0 name, etc. Yes, I may be guilty of that. I have at times posted a couple of versions without renaming when I found one or more problems in the distribution. I try to fix these before my official announcement, but the release process is really a bit broken in the sense that there is no way to test out compiles on multiple platforms when we don't have multiple platforms available. We would like to change this in the direction of having a group of designated system testers who compile a prerelease package on specific platforms to look for problems before we make an official release. We have been relying on things being found in the HEAD distribution, but of course there are those who wait each time for the official release, and when problems show up then, we have no choice but to issue a patch. If the patch is minor and system-specific, I have forgone the rev change in the process, which is certainly not ISO 9000. Thanks for your help and your feedback, James. I understand your job is not an easy one, and not always fun. Best, -Greg _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
