Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge with STEPToMesh (and STEPToPoints?) #4

Open
jmairboeck opened this issue Jun 27, 2022 · 2 comments
Open

merge with STEPToMesh (and STEPToPoints?) #4

jmairboeck opened this issue Jun 27, 2022 · 2 comments

Comments

@jmairboeck
Copy link
Contributor

For easier deployment (especially when linking statically) and to reduce code duplication and maintenance efforts between the STEP processing tools, it could make sense to merge them into a single project, producing a single binary which can be invoked in several modes, e.g. similar to how the command line clients of git or svn work.

Listing the contents of a STEP file (i.e. -c) could then be a dedicated mode because it is shared between all other processing modes.

The code for reading a STEP file, for parts selection and maybe specifying the working unit (see aleutgeb/STEPToMesh#4) could be shared.

@aleutgeb
Copy link
Owner

Hello,
we are following the design philosophy "Do one thing, and do it well" or "Single-responsibility principle". So currently there are no plans to merge the functionality.

@jmairboeck
Copy link
Contributor Author

We will keep the statically linked separate tools for now. Size-wise, two statically linked tools are still (slightly) smaller or nearly equal than using dynamic linking. My dynamically linked builds are about double in size than the static versions for both STEPToMesh and STEPToXSection. If we ever need a third one (e.g. STEPToPoints), we should probably switch to dynamic linking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants