combine PackageCompiler with static-julia #18
Conversation
plus it appears to crash the debugger, so i guess it is useful as an anti-disassembler?
Fix #2. Obviously we need to set things up so that these restrictions can be lifted.
Use Pkg.dir() by default instead of ~/.julia
Make JULIA_HOME the default installation directory.
Make the syslib extension .dylib on apple.
…argets Build only explicitly requested targets by default
* Avoid need to change program.c by providing name.
Changes juliac.jl to provide the name of the created shared lib
("libhello") to the c preprocessor as a macro, via "-D".
This way you do not need to modify the provided program.c when compiling
a new julia program.
Addresses issue #3.
* fix: Also use macro for libname in program2.c
* Update README to reflect macro defined libname.
Remove references from README to changing the image name manually in
`program.c`. Add note about the availability of the image lib name in
the C preprocessor macro.
* Rename lib-name macro variable; remove default val.
s/JULIA_LIB_NAME/JULIAC_JL_PROGRAM_LIBNAME/g;
Remove default value. The libname *must* be provided on the commandline
via `-DJULIAC_JL_PROGRAM_LIBNAME="libname"`.
* Update author information * Change "--auto" into "--autodeps" * Code tweaks * Add Julia v0.7 support
|
after discussing the future of PackageCompiler & static-julia, @ViralBShah and I concluded it would be nice to merge the efforts and include the features from static-julia into PackageCompiler. You may ask, why not include PackageCompiler into static-julia? CC: @lucatrv |
examples/program.c
Outdated
| // Cleanup and graceful exit | ||
| jl_atexit_hook(0); | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
example2.c is a better example file. I think we should just delete this one.
|
Also pinging @Keno @StefanKarpinski @vtjnash for their thoughts. I do thinking having all of this in a package is the right way to go for now to make it easy to install and make it available to package authors. |
|
👍 This also aligns well with my original goal of keeping |
|
Seems like a good idea to me as well. |
|
|
||
| function snoop(path, compilationfile, csv) | ||
| cd(@__DIR__) | ||
| # Snoop compiler can't handle the path as a variable, so we just create a file |
There was a problem hiding this comment.
I thought I had fixed many of the issues here in SnoopCompile (missing esc in macros, need for tmp_mod, some cases of bad printing). Are there issues filed for these?
There was a problem hiding this comment.
I will take a second look! I haven't filed any issues yet
Codecov Report
@@ Coverage Diff @@
## master #18 +/- ##
=========================================
- Coverage 61.97% 52.17% -9.8%
=========================================
Files 2 4 +2
Lines 142 230 +88
=========================================
+ Hits 88 120 +32
- Misses 54 110 +56
Continue to review full report at Codecov.
|
|
Please reconsider the name choices. I would keep the main script named |
|
Agree on retaining the name |
|
Fair enough! |
|
@SimonDanisch please notice also the name of the function |
|
I wanted to ship this branch with a simple working python wrapper ability, but I got into issues with linking mingw and msvc dll's for python ;) But the prototype is pretty close to completion beside that, and I will try later on linux - which should be a lot easier! |
|
@ViralBShah I would add a note on static-julia repository to refer users to PackageCompiler.jl. |
|
@SimonDanisch once you merge this I can submit next PRs for |
No description provided.