You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a question rather than an issue with port_compiler itself 🙂
I'm working on an Erlang project that relies on C code for one application. After successfully compiling code there are a bunch of artifacts and files created on two locations:
c_src
foo.d
foo.o
priv
foo.so
I'm wondering if foo.o could be created also on priv directory or any other location for that matter. I'm also wondering if I could tweak flags to produce foo.so only. Not that I'm very familiar with gcc or C code itself.
This is for caching purposes in the context of a Dockerfile with different steps for compiling and assembling releases. Basically I assumed that caching the final shared object after compilation would be enough, but it turns out that without the other *.o file compilation and linking gets triggered again when assembling a release. My first idea was to also generate that object file inside priv (already cached) but I didn't manage to find a way to do so. In the end something as simple as creating an empty foo.o file was enough to avoid that unnecessary extra compilation and linking, albeit very minor to be fair.
The text was updated successfully, but these errors were encountered:
Hi,
This is more of a question rather than an issue with port_compiler itself 🙂
I'm working on an Erlang project that relies on C code for one application. After successfully compiling code there are a bunch of artifacts and files created on two locations:
c_src
foo.d
foo.o
priv
foo.so
I'm wondering if
foo.o
could be created also onpriv
directory or any other location for that matter. I'm also wondering if I could tweak flags to producefoo.so
only. Not that I'm very familiar with gcc or C code itself.This is for caching purposes in the context of a Dockerfile with different steps for compiling and assembling releases. Basically I assumed that caching the final shared object after compilation would be enough, but it turns out that without the other
*.o
file compilation and linking gets triggered again when assembling a release. My first idea was to also generate that object file insidepriv
(already cached) but I didn't manage to find a way to do so. In the end something as simple as creating an emptyfoo.o
file was enough to avoid that unnecessary extra compilation and linking, albeit very minor to be fair.The text was updated successfully, but these errors were encountered: