Refactor/libs

[leissa]

Moves automaton into its dedicated lib and avoids double compilation.

• automaton stuff is now in its own lib independent from thorin and regex and gtest-regex simply link against libautomaton
• thorin/plug/regex/automaton -> automaton
• you can now build a thorin plugin as SHARED to also link normally against a plugin
• thorin-regex-gtest makes use of this feature

[leissa]

@fodinabor Can you have a look. The automaton stuff is now its own independent lib. I think this is more what you originally intended :)

[leissa]

@fodinabor bump

[fodinabor]

Sorry for the delay...

I am somewhat struggling to see the point in having the plugin as a (shared) library. For the gtest suite, there are the "whitebox" automaton tests, which could just as well link the automaton lib statically (I just was to lazy to make it a static lib) as could the regex plugin. When the regex plugins' passes are needed in the gtest suite, it loads the module (.so) anyways via the usual mechanics.

That is not to say that some of the changes might make sense nevertheless, but I don't really see a benefit of having the option for plugins to be compiled as either or..

[leissa]

I am somewhat struggling to see the point in having the plugin as a (shared) library. For the gtest suite, there are the "whitebox" automaton tests, which could just as well link the automaton lib statically (I just was to lazy to make it a static lib) as could the regex plugin. When the regex plugins' passes are needed in the gtest suite, it loads the module (.so) anyways via the usual mechanics.

Well, one part of my changes is to have the automaton lib as an ordinary lib (which is shared by default but you could also make it static - wouldn't change much). The bigger change is about allowing plugins as a SHARED as opposed to a MODULE lib. So what you are basically saying is that instead of linking against libthorin_regex.so to get access to dfa2matcher and regex2nfa, we should instead use dlopen and then invoke the pass over the usual machinery?
Well, yes, we can do that. Would simplify a couple of things again a bit and maybe add a few lines of boilerplate to gtest/automaton.cpp. I just wanted to get rid of the double compilation without delving too deeply in gtest/automaton.cpp.

[fodinabor]

I would've proposed to link both thorin_gtest and libthorin_regex.so statically against libautomaton.a. That should allow to use for the whitebox tests without dlopen and for the thorin IR tests rely on the implicit dlopen mechanics from the thorin driver as already done atm.. you would still remove the re-compilation, you would just link the static lib twice..

[leissa]

I would've proposed to link both thorin_gtest and libthorin_regex.so statically against libautomaton.a. That should allow to use for the whitebox tests without dlopen and for the thorin IR tests rely on the implicit dlopen mechanics from the thorin driver as already done atm.. you would still remove the re-compilation, you would just link the static lib twice..

As far as I can tell, lib automaton is not the issue here. It doesn't matter whether we link statically or dynamically, no?

I tried my latest commit to dynamically load regex2nfa but trouble is that this thing returns a non-trivial C++ class (std::unique_ptr<automaton::NFA>) that breaks C linkage.

[fodinabor]

Yeah, that's why I'd propose to have that statically linked, so we don't care about c linkage 🤔