<rgr[m]>
Leonidas: I'd need an exmaple that I can repro, copy_files seems to work just fine as in that example. So it might be something specific to your setup
<Leonidas>
rgr[m]: oh, nevermind. I had the copy_files in my library definitions as well which triggered the error
ygrek has joined #ocaml
bronsen has quit [Remote host closed the connection]
bronsen has joined #ocaml
keep_learning has quit [Remote host closed the connection]
<_xvilka_>
Leonidas: those are llvm only
<_xvilka_>
Leonidas: I need AST access
<_xvilka_>
kit_ty_kate: yeah, clangml looks very dead
kakadu has joined #ocaml
mfp has joined #ocaml
<Leonidas>
rgr[m]: where does copy_files copy things? I have created a vendor directory with a submodule and specified (copy_files vendor/*) but I don't see this being copyied.
<rgr[m]>
Somewhere in the _build directory
<rgr[m]>
copy_files always copies to the _build/**/jbuild dir where it's defined
spew has joined #ocaml
<Leonidas>
rgr[m]: default or install?
spew has quit [Read error: Connection reset by peer]
<rgr[m]>
_default
<rgr[m]>
install is the directory where jbuilder stages the things it's going to pass to opam-installer
<rgr[m]>
s/_default/default/
<Leonidas>
ah, right, makes sense
<Leonidas>
rgr[m]: to test this I have a (copy_files test) clause in my src/jbuild and an empty file src/test. But when I jbuilder build I get Recursive dependency between directories:
<Leonidas>
src
<rgr[m]>
Yes, you can't have this. copy_files must be copy from a dir that's outside it
<rgr[m]>
Anyway, it doesn't really make sense to copy a file into the dir where it exists
<Leonidas>
ok, so how do I get a file from src/test to the build directory?
<Leonidas>
(file or folder, in any case)
<rgr[m]>
ah so you have a test which has a file dependency, is that right?
<Leonidas>
rgr[m]: I have a C++ file which has dependencies on vendored include files and I'd like to move the vendor library in a way that I can reference them in cxx_flags
<rgr[m]>
Okay, so this is a problematic issue with jbuilder.
<rgr[m]>
Btw think of copy_files as "import sources"
<rgr[m]>
That's all it's good for. When your library or executable sources are spread across multiple dirs
<rgr[m]>
To solve your problem, you probably need to use self_stubs_archive
<_xvilka_>
btw, if I want to port old Camlp4 code to extension points, I need to learn Campl4 obviously, to write the plugin for camlp4-to-ppx. Is there any good definitive guide for writing Camlp4 extensions? The one which allows to dive into the writing them in a shortest available time?
andreas_ has quit [Quit: Connection closed for inactivity]
<kit_ty_kate>
_xvilka_: Maybe you can try to revive it ? I think there are not a lot of changes between 3.9 and 6.0
sh0t has joined #ocaml
silver has joined #ocaml
tarptaeya has joined #ocaml
<flux[m]>
Drup: 👍
demonimin has quit [Ping timeout: 264 seconds]
<flux[m]>
now all we need is merge to upstream as well :)
malc_ has left #ocaml ["ERC (IRC client for Emacs 27.0.50)"]
Haudegen has quit [Remote host closed the connection]
<Leonidas>
rgr[m]: :| This sort of sucks because that is the exact reason I wanted jbuilder to build the stubs to not have to deal with another yanky makefile abomination
spew has joined #ocaml
<rgr[m]>
But I assume the makefile abomination is vendored as well? If so, you no longer have to deal with it but interface to it
<rgr[m]>
jbuilder doesn't have a way to build C/C++ libs today and it's unclear if it will ever get such functionality.
<rgr[m]>
It's possible though, as jenga does it and it seems to work fine
<Leonidas>
rgr[m]: there is no makefile. it is include only, so the only thing I really need is to add the correct -I paths in cxx_flags.
<rgr[m]>
I see. Isn't adding the files in `(cxx_names (...))` enough?
<Leonidas>
rgr[m]: all of them? I'd have to recursively traverse the whole structure of nested includes to get all of them.
<rgr[m]>
:'( sorry
<rgr[m]>
ATM cxx_names doesn't have a glob language
zolk3ri has quit [Ping timeout: 264 seconds]
<Leonidas>
that's why I sort of just want to copy the vendor folder to _build/default/vendor and write `-I vendor` in cxx_flags.
<Leonidas>
Anyway, thanks for your help!
<rgr[m]>
but if there are so many files, are you sure they can be built so simply? don't they have their own dependencies/build order
<Leonidas>
But then what is copy_files good for?
zolk3ri has joined #ocaml
<rgr[m]>
copy_files is good for importing sources into a directory
<Leonidas>
rgr[m]: it is pretty simple, the Makefile is basically `g++ -shared -fPIC -std=c++14 -Wall -O3 -march=native $< -o $@ -I ./submodules/falconn/src/include -I ./submodules/falconn/external/eigen -pthread`
<Leonidas>
rgr[m]: ML sources, I assume
<Leonidas>
I can of course do (cxx_flags (-I ../../../submodules/falconn/src/include)) which works, but cd'ing out of _build feels sort of wrong
<rgr[m]>
Sure.
<rgr[m]>
It can work with other sources too, but things like stubs require you to specify all filenames
<rgr[m]>
I don't see how could copy_files help here anyway
<rgr[m]>
you're listing the include dirs either in the copy_files or elsewhere
<rgr[m]>
what's the difference
<rgr[m]>
but if you want, you could create some structure like this:
<rgr[m]>
vendor/jbuild <- this will contain all the copy_files stanzas
<rgr[m]>
vendor/submodules/falconn/src/include...
<rgr[m]>
and then you can simply use -I vendor
mbuf has quit [Quit: Leaving]
<Leonidas>
rgr[m]: I'll do it with ../../.. for now, but since this is planned to be opensourced soon I'll revisit it later. Then it will be easier to talk about these things because I can just point to the repo
sh0t has quit [Remote host closed the connection]
<rgr[m]>
Leonidas: np. feel free to make issues
<Leonidas>
rgr[m]: the reason I'd like to have it in copy_files is because I would sort-of like the build process to be contained in _build instead of .. out of it and then accessing random locations.
<rgr[m]>
Yeah, accessing files outside of _build is really a no-no btw
chelfi has joined #ocaml
Haudegen has joined #ocaml
gentauro has quit [Ping timeout: 276 seconds]
_andre has joined #ocaml
gentauro has joined #ocaml
gtrak has quit [Ping timeout: 256 seconds]
jao has joined #ocaml
jao has quit [Ping timeout: 264 seconds]
gtrak has joined #ocaml
webshinra has quit [Ping timeout: 255 seconds]
sh0t has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 260 seconds]
dhil has joined #ocaml
al-damiri has joined #ocaml
bairui has quit [Ping timeout: 240 seconds]
kakadu_ has joined #ocaml
kakadu has quit [Ping timeout: 276 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
kakadu has joined #ocaml
kakadu_ has quit [Ping timeout: 240 seconds]
webshinra has joined #ocaml
jao has joined #ocaml
bairui has joined #ocaml
<Drup>
rgr[m]: "Library "segments" is private, it cannot be a dependency of a public library." why ? :(
nicoo has quit [Remote host closed the connection]
nicoo has joined #ocaml
pierpa has joined #ocaml
failproofshark has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
samposm has joined #ocaml
zpe has quit [Ping timeout: 265 seconds]
onion has quit [Quit: WeeChat 1.9.1]
onion has joined #ocaml
onion is now known as whoman
whoman is now known as onion
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
tane has joined #ocaml
Exagone313 has quit [Quit: see ya!]
slash^ has joined #ocaml
Exagone313 has joined #ocaml
Exagone313 has quit [Remote host closed the connection]
zolk3ri has quit [Ping timeout: 276 seconds]
Exagone313 has joined #ocaml
ygrek has quit [Ping timeout: 263 seconds]
zolk3ri has joined #ocaml
Exagone313 has quit [Quit: see ya!]
Exagone313 has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
etc_ has joined #ocaml
<etc_>
Hi there! I'm trying to make a ppx that's able to run the typechecker against a module. In order to do this properly, I think I need the "include_dirs" for the file against which the ppx is running. Is there any way to get these include dirs within a ppx? I'm pretty sure Clflags.include_dirs lists the include dirs which the ppx was compile with, not the ocaml file it's running against.
<Drup>
etc_: the stuff in Clflags should be correct, if the ppx was called by ocamlc/ocamlopt
<Drup>
etc_: but, hmm, are you *really* sure you want a typing ppx ? It's best avoided unless you have really good reasons
j0sh has joined #ocaml
<etc_>
Drup: Hmm well the reason I am typing is because I want to get the module signature from a module path -- I don't suppose that's possible with a basic parsetree?
<companion_cube>
Drup: btw, ppx on typetree, do they exist? Do they go back to parsetree ?
<etc_>
companion_cube: yeah what I've done is convert back to a parsetree afterwords, working off of typpx's code
<Drup>
companion_cube: you don't want to modify the typedtree
jao has joined #ocaml
<Drup>
only oleg does that
<companion_cube>
heh, yeah
<companion_cube>
(where does he do that?)
<Drup>
metaocaml.
<etc_>
Drup: I'm using jbuilder to build the ppx and the testing file, not sure if that calls ocamlc/ocamlopt but probably right?
<Drup>
etc_: that's the point, typing ppx won't work with jbuilder's ppx handling
FreeBirdLjj has joined #ocaml
<Drup>
because jbuilder applies all the ppxs before even calling the compiler, as a pre-processing phase
<etc_>
Interesting, thanks! The other thought was to try to use a compiler plugin instead
<etc_>
do you know if that would work with jbuilder?
<companion_cube>
in practice, is a compiler plugin just a kind of internal ppx?
<Drup>
( companion_cube: if you are curious, he inserts full ∀α.α as type annotation in all the leaf because "hell why not", and he ships that to the later phase of the compiler :D)
<companion_cube>
ah well, let me look at the doc for compiler plugins…
<companion_cube>
Drup: wat
<Drup>
all the new leafs*
<Drup>
etc_: ask rgr[m]
<Drup>
I guess it would work better, yes
<Drup>
I'm not sure if the compiler plugin infrastructure is very usable yet, though
<Drup>
etc_: are you trying to reimplement ppx_import ?
<octachron>
companion_cube, if you are only using the parsetree hook, there is no real difference between ppx and compiler plugins; but there are more hooks