how do we deal with prebuilt library?

[hl4]

Is your feature request related to a problem? Please describe.
I want to include prebuilt library into the build system. e.g. the boost.filesystem library, unit-test-framework, openssl.

Describe the solution you'd like
We might introduce a configuration of the prebuilt library. e.g library may have name, header files, depends libraries and so on. we can load the config file while project is scanning. There are all binary component in evoke build system just like the builtin libraries.
We also can use the config for builtin libraries.

{
"boost_unit_test_framework": {
    "header": [
      "boost/test"
    ]
  },
  "boost_unittest_standalone": { 
    "headerOnly": true,
    "header": [
      "boost/test/included/unit_test.hpp"
    ]
  }
}

I found it hard to describe and to use the feature variant of prebuilt library. e.g. Boost.Asio library. They are introduced by feature macro, and resulted different library name and more dependancy.

additionally, we need to specify the platform, , runtime and debug variant of prebuilt library.

Describe alternatives you've considered
Should we only introduce those library built from source files?

Additional context
no more

[dascandy]

Good question. I've put up a draft in the root to make Evoke build itself with platform libraries - https://github.com/dascandy/evoke/blob/modules/packages.conf - which I seem to have committed to the modules branch. The syntax is pretty close to what you've defined so far, except based on (iirc) toml / the existing configuration file format. Right now, it does not take into account any configuration or toolset, so I know it's insufficient and in need of improvement.

Would you be willing to take that branch & explore where that feature leads?

[hl4]

Yes, I would like to.
Actually I had roughly implement the feature but in JSON syntax, within json11 parse library from dropbox. I might commit a pr later.

[hl4]

for discussion

each prebuilt binary file is a library/component. it implicts a configuration variant and can be used under compatible configuration.

the configuration may be encoded to the name of library file, just like boost did.

The critical information to use these library are which header file need the library. we may assume the prebuilt library has a predefined folder structure. We can scan the folder to get this info. such as

the-library-name/
   include/
   lib/
      libsomename.a
      libsomename-cfg.a
      libsomename-other-variant.a

But, It's hardly to define the dependancy of the library itself. for example, I found boost_system need link to ws2_32, and boost_filesystem obviously need boost_system. In this case, I think auto linking would be a good feature.

On the other hand, We should read those headers and libraries within compiler, in order to understand which header belongs to each libraries.

if we would use a configure file:

[boost_filesystem]
prefiex = "path-to-top-folder"
headers = "boost/filesystem"
depends = "boost_system"

[boost_filesystem.vc71]
depends = "ws2_32"

[boost_filesystem.d]
# for example
defines = "BOOST_DEBUG"
"stdc++" = "c++17"

we should decode the library name for vc71 and d.

[dascandy]

The description as you provide it just above is what is there now. It does not consider multiple variants of something to exist at all, so there's a point to improve on it.

What's there now works for me, but I see many places where it could do with improvement.

[hl4]

Great work! but there are still some issue.

stdc++fs library is not always exist, but evoke try to link it all the time.
It's hard to fix.

1. evoke don't support conditional macro(#if). we found both stdc++fs and boost::filesystem from fw/filesystem.hpp
2. packages is not supported specify toolset. In my opinion, it may be too complicate to specify toolset and version.

[JulienGrv]

@hl4 regarding 1. We could parse the source code using clang. It resolves macros.

Example: https://shaharmike.com/cpp/libclang/

Edit: add link to example

[dascandy]

Using clang removes one bit of problems, in exchange for lots more. Clang has entirely different goals.

Fundamentally, Evoke's approach does not support macros, and your code dependency graph should not depend (fundamentally) on macros.

Prebuilt libraries are now imported using packages.conf and after a few years of using this, for me it works really well. They basically are for your host platform, and for specific cross-platform builds. Those need a separate packages.conf which is not in right now, but the approach at least seems good.