At 17:35 Uhr +0100 13.03.2002, Bernd Kuemmerlen wrote: >Hi there, > >today I stumbled upon a problem in the dcmtk-3.5.1 package I made (which >is included in finks unstable branch): > >dcmtk installs a bunch of headers into a directory structure which is >normally located at /usr/local/dicom/include/ > >There are some header files which go directly into this directory, and a >lot more in subdirectories for the different parts of dcmtk. > >In my package, I just set the prefix=%i, so a few headers are installed >to %p/include. And this is the problem because one of these headers is >config.h. Obviously this is a BadThing and breaks compilation of a lot >of packages because their config.h is not included... :-( (This also >violates one of fink's filesystem rules, I know).
Yeah, config.h should never be installed. Also, installation (during package build time I mean) should always occur into %i/include. Files should only be moved into %p/include by Fink... maybe you meant that, it wasn't quite clear to me. >I want to fix this, but I have some questions about that: >What would be the best way to put the headers into a new location? I >can't just set prefix to something like %i/include/dcmtk because this >results in a wrong hierarchy from there (%p/include/dcmtk/include and >%p/include/dcmtk/lib). It seems that I can't set the includedir from the >commandline, this is set in a global Makefile.def. > >The two options I see are: >- patch Makefile.def to put the headers somewhere else, not in >$(prefix)/include >- move the headers to a different directory in the InstallScript > >Any other hints/suggestions? No, what you say makes sense. In these cases, I usually prefer to fix the build system of the package. Ideally, you do that in a clear fashion, i.e. so that it remains usable on other systems, then you can try to submit it back to the upstream maintainer for future versions of that software. While you are at it, you could even try to implement DESTDIR, but don't bother if it's to much work. On Unix, it's sort of a convention to suppor the prefix/bindir/libdir/... etc. variables, even in build systems not based on autoconf/automake. Supporting it, or a functionaly equivalent, is paramount for a truly portable package, try to to explain that to them in nice words, and they might listen to you :-) >Another question is: How do I make sure that the "bad" headers are >removed when somebody updates to the new version of the package? Where are the "bad" headers located right now? I am not quite sure I understood it... do you mean they are in.. a) /usr/local/include b) /sw/include c) somewhere else; and do they include config.h ? For each scenario I'd treat it slightly different. >Sorry if some of the questions seem to obvious, but I am just >starting... No, it's perfectly OK to ask this (sorry, I just kind of overlooked your mail previously.) Cheers, Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
