On Thu, Nov 4, 2010 at 12:49 AM, Noah Slater <nsla...@apache.org> wrote: > > On 4 Nov 2010, at 04:41, Paul Davis wrote: > >> The issue with configure.ac is that it is a pre-distribution method >> for configuring a build system. As in, if we claim some functionality >> for Erlang builds via configure.ac, then we're tacitly making the >> claim that we'll have multiple distributions, a "rebar distribution" >> and a "erlc distribution". Its not unfathomable to me that we just say >> "tarballs will use erlc" which is not out of the question, but it >> still seems weird. > > Nu, uh... > > `./configure` is run during every local install. > > What I described is possible for every single individual user. >
Oh right. For some reason I was thinking you were saying to put the "erlc vs rebar" decision in configure.ac instead of "generate the logic to decide when ./configure is run." Hence why you are sempi. >> The other issue is that I do realize that we can leverage ./configure >> to (for lack of alternate verb) configure the build. The issue with >> rebar and VPATH builds is that reading the docs and source code, I >> could not see any method to tell rebar "your source files are in this >> place, place your output in this other place." As I read rebar's >> source, its output paths are absolutely defined by the input file >> name. I'm guessing that Noah is incredulous by this claim, but I will >> remind him that rebar is awesome precisely because of this sort of >> prejudice, its just not VPATH aware. > > So, it's output files are in predictable locations? > > Sounds like a good opportunity for post-hoc installation logic. :) > > Either way, I see it like this: > > - Before build time we can control what rebar sees. > > - After build time, we can modify and move files as we want. > > What more could you possibly ask for? > > Except for the problem to go away entirely, of course. :) > Quite predictable locations. But the way we would predict what goes where would basically be to copy portions of the source tree to the build tree before invoking rebar. Its not out of the question, but seems "not quite right". >> Also, writable source trees. I know Noah knows this, but people that >> aren't familiar with VPATH often get tripped up on this. The key thing >> that made this click for me was to imagine expanding a tarball, >> writing the source code to a CD, and then building and installing from >> that CD without copying source files. > > Good catch, I forget to mention a lot of this stuff. :) > >> I think that's the right sentiment, but slightly not quite right I >> think. The analogy I would use would be more like, "Reconciling Erlang >> builds with Autotools builds is like trying to translate poetry from >> Turkish to Navajo." > > Actually, I think it should be perfectly surmountable. The key will be in > separating the Erlang build from the main build. Think of it like compiling a > C app. You wouldn't have the compiler try to move the files into location, or > handle the installation of the /etc/config/file. So, just treat rebar, or > whatever, as the compilation step for an OTP app (even though the result is a > directory tree, a bit like NeXT really) and use Autotools to plop that into > the right location on the filesystem. Exactly. I think its quite possible, I just don't speak Autofu as fluently as you to know what the "elegant" solution would be here. My concern is if our 'surmounting effort' turns into a "'oh fuck, that doesn't work on Solaris 3.3 when running on a Sparc Ultra2400 with the 32GiB RAM expansion while PXE booting off a Broadcom 802.11k chipset.' effort". I'm just saying... HTH, Paul Davis
