Some .hrl files count as interfaces - a particular case being "public" record definitions made in header files. <div><br></div><div>Usually, if a .hrl contains "application private" definitions, I'm inclined to leave it in src. If it includes "public" definitions then I'd drop it in include.<div><br></div><div>Probably the greatest case for having .ez files is libraries -- where the public api is the most important.</div><div><br></div><div>So I'd support +1 the idea that .hrl files should be accessible from within a zipped ez - even if constrained (or maybe should be so?) to just an include directory...</div><div><br></div><div>My 2c</div><div>/s<br><br>On Tuesday, March 6, 2012 10:29:57 AM UTC-6, Tim Watson wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style="word-wrap:break-word"><div>In general, I think .ez archives are an ideal unit of packaging and distribution (as dependencies) and therefore making them fully self contained is very helpful. If you specify 'lager >= 1.0.2' as a dependency and all I have to do is find and fetch the archive (and check the MD5 and whatnot) then stick it somewhere useful on the machine, the subsequent build (handling of dependent packages), release assembly and other things just work really nicely. Having to 'manually' pull the includes out before being able to utilise the archive as a compile time dependency is just a bit annoying for tools authors that's all. <br></div><div><br></div></div></blockquote></div></div>