microsoft / ifc

SDK for the IFC specification at https://github.com/microsoft/ifc-spec

IFC SDK

The IFC SDK provides datatypes and code supporting the read and write of IFC files. This is an experimental project aiming at advancing implementation and uses of C++ Modules at large. The SDK contains C++ datatypes that can be memory-mapped directly onto the on-disk format. See the IFC Specification for more details.

If you want to participate in the development of the IFC SDK, you are welcome! You can report issues, comment on pull requests, and learn about what we are working on. You can also submit pull requests to fix bugs or add features reflecting the Specification: see CONTRIBUTING.md for more information.

Building and Running

This project uses CMake for defining projects, and the code has been tested to work on Windows and Linux. It can be built and run under WSL (Windows Subsystem for Linux) as well.

The JavaScript IFC viewer can be run by loading the index.html file in a browser.

IFC files to experiment with can be generated by using a current Microsoft C++ compiler. There are a couple of IFC files checked into the repo for basic testing purposes. Longer term, we want to be able to generate IFC files using the SDK itself. To generate an IFC file, you can use a current Visual C++ compiler. The following will generate an IFC containing almost everything in the test.cpp translation unit. Currently, non-inline functions or methods will not be generated into the IFC.

cl /std:c++20 /exportHeader test.cpp

This will create an IFC file named test.cpp.ifc. This can be dumped with ifc-printer like this.

ifc-printer.exe --color test.cpp.ifc

See BUILDING.md for more information.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to grant us the right to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR (Pull Request) appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

See CONTRIBUTING.md for more information.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

Microsoft Open Source Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct.

Resources:

• Microsoft Open Source Code of Conduct
• Microsoft Code of Conduct FAQ
• Contact [email protected] with questions or concerns

License

Copyright (c) Microsoft Corporation.

SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

ifc's Issues

Packaging (vcpkg, etc)

Once there is a 0.43.1 tag, I think it'd be time to prepare a vcpkg port for the project for easy consumption.

Since the package name for the CMake package followed the GSL pattern, should this project also be packaged as ms-ifc? Maybe even ms-ifc-sdk?

Determine package interface

The current CMake files do not support reuse by clients due to the missing install rules and missing CMake package. I would like to know what would be the way for people to consume this SDK.

Being careful not to cause potential name conflicts with packages dealing with CAD applications' Industry Foundation Classes (.ifc), I think this would be one way for a consumer to use this SDK:

# the package name is MicrosoftIFC, found in e.g. <prefix>/lib/cmake/MicrosoftIFC
find_package(MicrosoftIFC REQUIRED)

# the SDK target is an interface target that link both ifc-dom and ifc-reader, as a convenient all in one target
target_link_libraries(AwesomeIFCConsumer PRIVATE MicrosoftIFC::SDK)

I would like to work on this once the requirements are known.

Static analysis in CI

The contributing document suggests that contributors ought to format the code before submission, however there is no enforcement in CI. I would like to add it to the CI, however it's not stated which version of clang-format should be used. Different versions of clang-format may format some code differently, so it's important to specify the version.

On the same note, I'd like to also know your opinions on other forms of static analysis, such as spell checking. I have been using codespell personally. If you find it satisfactory, I'd also like to add that in the same PR.

To make efficient use of CI resources, I would like to structure CI as a single file with such job and matrix configuration:

flowchart
    A["clang-format
    codespell"]
    B["CMake (Windows)
    CMake (Ubuntu)"]
    C["CodeQL (Windows)
    CodeQL (Ubuntu)"]
    A --> B
    A --> C

You can see this example, where nothing else is done until the lint job is done.

Making this chart also makes me question whether the separate CMake jobs are necessary with CodeQL jobs being a thing.

Don't throw exception of built-in types

During the review of #30 , @menuet correctly observed there is existing code that violated Core Guidelines E.14. That should have been caught before it was checked in. Upon further logic inspection, it looks like that the Reader constructor was detecting too late an erroneous condition. Move that detection earlier, at the very minimum, at the site of the Reader object construction.

Raise minimum required CMake version to 3.27

That allows requesting build of main branch with C++23, and conformance mode for MSVC and reducing /Zc flags soup. Furthermore, that allows modular experiments with close to main baseline.

Unit tests

Hi,
While trying to contribute #52, I was wondering how I could add a unit test accordingly (add a sample ifc file provoking InvalidPartitionName and catching the exception, for instance).
But I don't see any unit tests in the project.
What is the currently recommended testing process?

How to build on Linux?

Doc states "the code has been tested to work on Windows and Linux". I guess the Linux part means in Windows under WSL, correct?

A quick attempt to build on Linux (no WSL) is giving me this error:

CMake Error at CMakeLists.txt:19 (find_package):
  By not providing "FindMicrosoft.GSL.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "Microsoft.GSL", but CMake did not find one.

  Could not find a package configuration file provided by "Microsoft.GSL"
  with any of the following names:

    Microsoft.GSLConfig.cmake
    microsoft.gsl-config.cmake

  Add the installation prefix of "Microsoft.GSL" to CMAKE_PREFIX_PATH or set
  "Microsoft.GSL_DIR" to a directory containing one of the above files.  If
  "Microsoft.GSL" provides a separate development package or SDK, be sure it
  has been installed.


-- Configuring incomplete, errors occurred!