[Zlib-devel] zlib-1.2.3-cos4

[Enrico Weigelt]

* Mark Adler <madler at alumni.caltech.edu> schrieb:

<snip>

> On Aug 18, 2006, at 7:25 AM, Enrico Weigelt wrote:
> > You should fix your filename assiocations to handle .h.in properly.
> 
> Mac OS X doesn't seem to recognize the concept of extensions with  
> dots in them.  (I tried that once before with .tar.gz).

Fix you OS ? ;-P

Well, if OSX was open, it probably would have been already fixed ...

hmm, if it's just opening a file in an external program, you
could assign .in with an shell script, which checks the filename
and calls the proper editor.

<snip>
 
> > BTW: for strict logic:
> >
> > .h.in/.h.in is *not* the same type as .h, as well as .h.y isn't.
> > Its an template/input for generating .h somehow.
> 
> Well in this case zconf.in.h is in fact a .h file, and that's how I  
> want to edit it.  It is not a ".in" file, whatever that might mean.   

hmm, just had a deeper look at it ...

well, most things could be moved out to an separate .h file, just 
the actual configuring remaining. This then probably won't need 
any template/input anymore, just echo'in the proper #define's to
some file.

<snip>

> We seem stuck with operating systems that use file extensions to  
> figure out what they are.  (BeOS fixed that with mandatory metadata,  
> but where the heck did it end up?)

metadata is an interesting idea, but it's quite useless in 
heterogenous environments, and even when youf FS doesn't support them.
Mapping filenames to mimetypes via some regex seems quite usable. 

BTW: maybe someone remembers Oberon ? When working on an FAT
filesystem, it stored some special (hidden) file in each dir,
so it could store metadata and long filenames. 
Maybe would be an interesting project to develop an standard
format for storing such metadata in an application independent
way, so lots of apps (ie. certain DE's) can easily use it without
conflicting each other or loosing data. But, that becomes OT ...

> I still can't figure out what's wrong with .in.h, but since everyone  
> seems convinced that God intended for it to be .h.in, I will see if I  
> can accommodate both with the least amount of ugliness.

Well, it's an kind of standard. People are used this scheme.
And (IMHO) it's more obvious: it's an input file, which later 
becomes an .h.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------