Support clients using CMake

[friendlyanon]

Supporting clients using CMake requires that a project provides a CMake
package that can be found via find_package().

The package name was first suggested to be MicrosoftIFC in #29, but to
follow the pattern of GSL I changed it to Microsoft.IFC, which is still
very similar.

The package exports 3 targets:

• Microsoft.IFC::Core
• Microsoft.IFC::DOM
• Microsoft.IFC::SDK

Microsoft.IFC::SDK is just an interface target, which links to the other
targets as a convenient all-in-one target. This enables usage like so:

find_package(Microsoft.IFC REQUIRED)
target_link_libraries(project_target PRIVATE Microsoft.IFC::SDK)

The ifc-printer executable was made an opt-in target.

The project now also has an opt-in developer mode option for its
developers via the DEVELOPER_MODE cache variable, which will enable the
printer target and make testing available.

For people who wish not to use vcpkg to fetch GSL, an opt-in find module
is provided to download and setup GSL for the project by providing the
cmake/find directory via the CMAKE_MODULE_PATH command line option. This
can be done depending on your shell like so:

# cmd
-D "CMAKE_MODULE_PATH:PATH=%cd%\cmake\find"
# pwsh & POSIX shell
-D "CMAKE_MODULE_PATH:PATH=$PWD/cmake/find"

Fixes: #29

[GabrielDosReis]

but to follow the pattern of GSL I changed it to Microsoft.IFC

I like this even better. Thanks!

[GabrielDosReis]

Microsoft.IFC::SDK is just an interface target, which links to the other targets as a convenient all-in-one target.

So, linking against Microsoft.IFC::SDK as target will pull in all the other targets? What would it take to have a "core" library (that would have been the SDK target in my mind) that can be target without pulling in ifc-dom and friends? In that model, the ifc-dom, the ifc-printer and friends would link against the "core" library as target.

Thanks a bunch for working on this.

[GabrielDosReis]

So, linking against Microsoft.IFC::SDK as target will pull in all the other targets? What would it take to have a "core" library (that would have been the SDK target in my mind) that can be target without pulling in ifc-dom and friends? In that model, the ifc-dom, the ifc-printer and friends would link against the "core" library as target.

It looks like my idea of "core" lib is actually Microsoft.IFC::ifc-reader in your PR; I am fine with that, though I would suggest to rename that to Microsoft.IFC::Core

[friendlyanon]

So if I understand correctly (target -> how it appears in the install interface):

• ifc-reader -> Microsoft.IFC::Core
• ifc-dom -> Microsoft.IFC::ifc-dom

And do away with SDK?

[GabrielDosReis]

So if I understand correctly (target -> how it appears in the install interface):

• ifc-reader -> Microsoft.IFC::Core
• ifc-dom -> Microsoft.IFC::ifc-dom

And do away with SDK?

No, sorry keep SDK after renaming if-reader to Core. I should have been clearer in my second comment.

[whoan]

Did you choose . for any particular reason? I am changing it to bin in my env so I don't need to change my PATH if, for example, I install it with prefix /usr/local

ie: I think it's better to have it in /usr/local/bin/ifc-printer than just /usr/local/ifc-printer

[GabrielDosReis]

I think it's better to have it in /usr/local/bin/ifc-printer than just /usr/local/ifc-printer

Agreed. I should have spotted that during review.