<kentonv>
well, in theory incremental builds should work if you haven't touched anything
<isd>
I literally did make then make install.
<kentonv>
the entire ekam sub-build is a single make step that has everything under 'src' as input, but if you haven't touched anything there then it shouldn't run again
<kentonv>
I have occasionally seen it not seem to work right, though. But haven't tracked down why.
<isd>
Fair enough.
<kentonv>
and yeah, Ekam itself does have incremental builds as long as it's running in continuous mode. :)
<kentonv>
not aware of anyone else using Ekam
<isd>
Right, but the point was just that folks who are used to the usual [ ./configure ] ; make ; make install are going to be surprised. If it's supposed to work though that's a different story.
samba_ has joined #sandstorm
anthropy has quit [Ping timeout: 245 seconds]
samba_ has quit [Ping timeout: 252 seconds]
anthropy has joined #sandstorm
aldeka_limechat has quit [Remote host closed the connection]
aldeka_limechat has joined #sandstorm
samba_ has joined #sandstorm
aldeka_limechat has quit [Ping timeout: 245 seconds]
jadewang has quit []
jemc has quit [Ping timeout: 246 seconds]
_whitelogger has joined #sandstorm
bodisiw has joined #sandstorm
jadewang has joined #sandstorm
jemc has joined #sandstorm
jadewang has quit []
bodisiw has quit [Quit: This computer has gone to sleep]
anthropy1 has joined #sandstorm
anthropy has quit [Quit: Leaving.]
anthropy1 has quit [Client Quit]
bodisiw has joined #sandstorm
bodisiw has quit [Client Quit]
jemc has quit [Ping timeout: 252 seconds]
wolcen has joined #sandstorm
n8a has quit [Ping timeout: 248 seconds]
n8a has joined #sandstorm
wolcen has quit [Ping timeout: 258 seconds]
anthropy has joined #sandstorm
samba_ has quit [Ping timeout: 258 seconds]
neynah has joined #sandstorm
anthropy has quit [Read error: Connection reset by peer]
xet7 has quit [Read error: Connection reset by peer]
xet7 has joined #sandstorm
wolcen has joined #sandstorm
samba_ has joined #sandstorm
<maurer>
kentonv: If you were building it all again from scratch, would you use ekam again? e.g. is it just that you haven't gotten around to making ekam mature yet, or "it ain't broke don't fix it"
<maurer>
(this is semi-orthogonal, just reminded me of my earlier confusions with ekam)
<kentonv>
maurer: I very much like working with Ekam. I would like to make it more mature, but so much to do, so little time...
<maurer>
Yeah, I definitely understand that, I was just curious
<maurer>
(since you have kj, capnproto, ekam, and sandstorm, which is a lot of live projects for one person)
<kentonv>
admittedly the instant-feedback aspect is no longer that necessary now that editors integrate libclang
<kentonv>
but I still like being able to create a new source file and just start editing without also modifying some makefile... but maybe that's not a huge value anymore, I dunno
<maurer>
The main thing that rubbed me the wrong way was the virtual filesystem hack
<maurer>
I kind of understand why you did it, but since I generally dislike the vendoring pattern, it didn't seem as nice to me
<kentonv>
you don't like how ekam does vendoring or you don't like vendoring in general?
<maurer>
I don't like vendoring in general; the build system messing with the filesystem separately strikes me as icky
<maurer>
well, with the view of the filesystem
samba_ has quit [Ping timeout: 260 seconds]
<maurer>
And since it's a hack to better support vendoring, I may be less able to see its redeeming qualities
<maurer>
(e.g. I'm trying to admit that I may be biased against the virtual fs layer more than a normal user)
<kentonv>
hmm, I don't really see it as being about vendoring. The point of the virtual filesystem and syscall interception is to auto-detect dependencies, rather than write them in a file (where that file could be wrong).
<maurer>
I thought the point was so that vendored deps showed up in the namespace in a clean way, but obviously you designed/wrote it
<maurer>
If you were just detecting dependencies, why do you need to do anything other than log the reads/writes?
<kentonv>
well, the only way the VFS differs in structure from the actual FS is that "src" and "tmp" get merged.
<kentonv>
this keeps generated files separate from source while letting the compilers and such treat generated inputs no different from source input
<kentonv>
oh, I suppose the VFS also has the by-tag search path which doesn't necessarily have anything to do with the real filesystem
<kentonv>
but that's not really used that heavily in practice
<maurer>
Unfortunately it's been months since I looked at ekam, so I don't remember the details of why it seemed confusing
<maurer>
I recall it was when I was trying to do an ekam build where each source was fetched separately, since network-access phase happened ahead of build-time-phase
<maurer>
and the vfs was confusing me somehow
<maurer>
Sorry, that's not super constructive. If I hit it again I'll try to write up the confusion more specifically.
<kentonv>
ok. :)
<kentonv>
it's definitely messy and confusing at present