crystal-data / gr.cr Goto Github PK

I grew up with Ruby as my first language; I know very little about C and lower layers. So it is difficult to accurately describe the problem. Still, I will write as much as I know.

The compile flags for GR.cr are copied from the original Dr. Makino implementation.

@[Link(ldflags: "-L `echo $GRDIR`/lib -lGR -Wl,-rpath,`echo $GRDIR`/lib")]

I used Crystal's macro to add a conditional branch for when the environment variable GRDIR is set and when it is not.

{% if env("GRDIR") %}
  @[Link(ldflags: "-L `echo $GRDIR/lib` -lGR -Wl,-rpath,`echo $GRDIR/lib`")]
{% else %}
  @[Link("gr")] # pkg-config
{% end %}

Here are some factors to consider.

• OS
  • mac OS
  • Ubuntu
• GR Framework
  • Official binary
  • homebrew
  • apt (OBS)
• Crystal
  • crystal build
  • crystal i

I use Ubuntu and APT. In this case, GRDIR must be specified before execution. PKG_CONFIG_PATH must be set for pkg-config to detect APT (OBS) packages. I believe that is done correctly. On the other hand, when using Crystal's interpreter, it does not work when GRDIR is set. pkg-config works fine.

Why? I don't know but I think this has something to do with -rpath ?.

Oddly enough, on macOS + homebrew, pkg-config seems to work as expected even if GRDIR is not set. I have not tried crystal i on macOS.

One of the most wonderful features of GR is the GRM module. This is a module that takes advantage of the variable-length arguments of the C language, and by creating GRM bindings, you can immediately use practical visualization in any programming language. This is great.

However, GRM is a relatively new module. The old GR bindings, such as the Julia binding, do not use GRM. The high-level API is implemented in Julia. It is more advanced than GRM. However, re-implementing this in Crystal would be a challenge.

I don't have much time to devote to developing GR.cr, so I think it would be better to create a thin wrapper for GRM and make it a higher level API.