drop boost regex requirement?

[Xeverous]

Elements requires boost::regex in CMake files but there is not a single use of any regex in the repository.

[djowel]

It is used indirectly by one boost library. I forgot which. Try dropping it and see the linker errors.

[Xeverous]

No linker errors after removing boost regex. Also, if some library is using boost regex, then it is a bug in that library's CMake files that it does not correctly expose all build requirements. One of modern CMake principles is that you should not care about transitive requirements.

[djowel]

No linker errors after removing boost regex. Also, if some library is using boost regex, then it is a bug in that library's CMake files that it does not correctly expose all build requirements. One of modern CMake principles is that you should not care about transitive requirements.

Ah I just noticed that in recent versions of Boost, BTW. Which version are you using?

[djowel]

No linker errors after removing boost regex. Also, if some library is using boost regex, then it is a bug in that library's CMake files that it does not correctly expose all build requirements. One of modern CMake principles is that you should not care about transitive requirements.

Ah I just noticed that in recent versions of Boost, BTW. Which version are you using?

OK, that change was introduced in 7bbec72 which coincides with working in Windows, so the linker errors probably happened with Visual Studio 2019 and Boost 1.71

[djowel]

No linker errors after removing boost regex. Also, if some library is using boost regex, then it is a bug in that library's CMake files that it does not correctly expose all build requirements. One of modern CMake principles is that you should not care about transitive requirements.

Ah I just noticed that in recent versions of Boost, BTW. Which version are you using?

OK, that change was introduced in 7bbec72 which coincides with working in Windows, so the linker errors probably happened with Visual Studio 2019 and Boost 1.71

@Xeverous one thing that would definitely help is if we could have CI working, so we can at least check building on different platforms. I am also looking at ways to test. I'm a test-driven person and I find it awkward that I do not have tests. The only library I wrote without it. Testing GUIs and graphics is kinda tricky, but I probably have some ideas.

[Xeverous]

So far I was building elements using various MinGW versions and boost 1.69 - 1.72. No problems. If you don't use date_time's string-related methods you can also drop this once - without them boost date time library is header-only.

[djowel]

So far I was building elements using various MinGW versions and boost 1.69 - 1.72. No problems. If you don't use date_time's string-related methods you can also drop this once - without them boost date time library is header-only.

Yeah, I know... I just don't have time to investigate.

Feel free to investigate what's happening with VS2019. It's probably a cmake thing. I can't remove the dependency now due to this issue. Try to follow the install procedure here: http://cycfi.github.io/elements/setup and see what you can do to remove the deps.

[Xeverous]

Elements already require building some parts boost and the GCC distro I currently use has a lot of library prebuilds (including boost) so I save a lot of time thanks to it. Don't expect me to check this soon. Linking unnecessary things is not a high-prority issue for me (more of a correctness issue) and if I see something is unneeded, I can drop it anyway (like I already patch scaling).

[djowel]

Linking unnecessary things is not a high-prority issue for me

And same for me. There are a lot more important things to do.

[Xeverous]

This is now outdated. We have actually dropped all compiled boost libraries.

[djowel]

This is now outdated. We have actually dropped all compiled boost libraries.

Yes we did. It took a while for me to figure out what's pulling all those libraries. It wasn't a high priority back then, but it stuck out like a sore thumb.