<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 28, 2017 at 7:57 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-09-28 10:37 GMT-07:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Sep 28, 2017 at 9:46 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-4218095205774470414m_-6889126931737582998h5">2017-09-28 8:48 GMT-07:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> Where would license files go on a make install?<br>
<br>
</span>"$CLANG_INSTALL_DIR/share/llvm/licenses"? Eventually make the path it an option?<br>
<div class="m_-4218095205774470414m_-6889126931737582998m_4084837203426538358m_2365711835599172909HOEnZb"><div class="m_-4218095205774470414m_-6889126931737582998m_4084837203426538358m_2365711835599172909h5"><br></div></div></blockquote><div><br></div></span><div>At least in linux land, most distros have places they expect licenses to go, and it's often part of the packaging format itself.</div><div>For example, debian expects copyright notices to be part of packaging, not installed by the package.<br></div><div>(IE what the patch originally does).</div><div><br></div><div>In particular, it expects it to be a machine parseable format in debian/copyright in the .deb package file.</div><div><br></div><div>This is in turn, parsed and a formatted version put in the right place in the distro.</div><div>They do *not* want packages installing them themselves, AFAIK.</div><div><br></div><div>While i understand why you think this logic should be common, IMHO, it shouldn't be.</div><div><br></div><div>Every single packaging/etc system has a different format, set of rules, etc for what should be happening here.</div><div>There is no real common logic you can extract from this.</div><div><br></div><div>You are going to write logic for rpms, debian, docker, etc anyway right now, to put the bits in the formats and places the distros want them.</div><div><br></div><div>I wish it wasn't the case, of course.</div></div></div></div></blockquote><div><br></div><div><br></div></div></div><div>What I'm saying is there is an apparent need to have in tree:</div><div><br></div><div>1) a way to collect the list of licenses files that needs to be distributed with LLVM.</div><div>2) a way to package them with a LLVM binary distribution.</div><div>3) duplicating this in tree seems bad and not maintainable.</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>I agree, but if every single packaging format wants #1 and #2 in different formats and containing different things, how do you expect to build any common functionality here?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>And considering that we haven't even be able to comply with our own distribution (!!) on <a href="http://llvm.org" target="_blank">llvm.org</a>, providing it in the most common unit seems the way to go.</div><div><br></div><div>My assessment right now is that I don't see any drawback to provide this *option* in LLVM and use the CMake option from docker, but on the opposite I see benefits to do it (the LLVM release scripts can be updated to use it right now).</div></div></div></div></blockquote><div><br></div></span><div>Meanwhile, i see no real benefit if every packaging has to turn it off and do something on their own anyway :)</div><div><br></div></div></div></div>
</blockquote></div><br></div></div><div dir="ltr"><div class="gmail_extra">I mentioned *two* in-tree packaging that would do the same thing (the LLVM release scripts and the Docker scripts. Two is the right number to factor things isn't it? ;)</div></div></blockquote><div><br></div><div>Most people I know would say it's three :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">And I mentioned a CMake option that would be an opt-in, that does not put any burden to turn it off for distribution.</div></div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Mehdi</div><div class="gmail_extra"><br></div></div></blockquote></div></div>