@starseeker FYI, the inclusion of nearly all tinygltf was intentional -- I messaged on teams, but the gist is that was a working setup with sample data and examples that this semester's students were given as a starting point. plus, I think it'll simply be less effort to manage as updates to tinygltf are expected possibly repeatedly over the next couple months while they work. I don't know their plans for that code yet, we may not even keep it as it's a working reference.
Can we put it in src/other/ext? It's pretty messy for the main tree
I mean, nothing else uses it and probably never will...
that's the pattern we used elsewhere when something is only used once
fyi I was also thinking to apply the same dist inclusion pattern I settled on there as it solves the problem of quoting files and needing to know the var name
I hate cluttering up the main tree that way... when I do that elsewhere, I usually make an effort to strip things down to a minimal core
I'll put it back for the student efforts, but I'm not crazy about it.
Give me a minute so I can try and do it without breaking the regress checks.
There's two concerns, there's clutter in the tree and there's maintainability across updates too. I'd think there's considerably less effort overall the less we modify 3rd party deps, no matter where they are. openNURBS being a great example of edits essentially halting maintenance and development.
all to save a few bytes or reduce a directory listing a few lines, which I don't think impose a technical problem (presently at least), more an aesthetic one
To me it's more than just aesthetics - when something goes into the main tree, I want to be able to understand easily why its there. As an ideal, I'd like to be able to look at every file in the source tree that's not in src/other or misc/tools and be able to identify why it's there from a BRL-CAD perspective.
What makes it feel like clutter? Or what's the consequence/effect? we have another example in src/libged/bullet where even the bullet source files are hundreds of lines, and they're necessary for the feature, but don't appear to appreciably affect anything by being in the tree
(other than the same consequence as other libs -- since it's not a drop-in, I can't update and test the latest bullet without considerable effort)
bullet should be in src/other/ext - it was my own technical inability to get it working successfully (on Windows, IIRC) any other way that landed it there.
Anyway, I'll get the gltf stuff back for the students.
starseeker said:
To me it's more than just aesthetics - when something goes into the main tree, I want to be able to understand easily why its there.
but isn't saying "src/conv/gltf/tinygltf is there because that's tinygltf and gltf-g uses tinygltf"? at least it is in my mind, though I could see a case for something like src/conv/gltf/other/tinygltf or src/conv/gltf/ext/tinygltf to really indicate in the path itself that it's a local dependency, and graduate to src/other when it's multiply used.
The latter would be better in that the repository checking tools could be taught more easily to treat those patterns differently
I mean I'd also be cool putting ALL external deps in src/other, but that seems like additional work for little benefit, especially for header-only stuff or single file situations. hard to justify.
I guess I could see a convention where anything inside an */ext/ directory is handled as external source code, and it wouldn't have to necessarily be in src/other
But I'd want some convention like that, which makes it clear that our standards for organization, build flags, etc. don't need to apply.
we should figure something out, as I see that really being an issue for GCV.
(which notionally is where gltf will land by the time summer is here)
I was going to try and move one of the other converters to get a feel for the effort needed.
Agreed. I'll go ahead and put it back for now, once I figure out how to do so without the github CI checks breaking, but I would like to have some definite scheme in place.
okay, definitely appreciated for this -- I literally just showcased the folder to them yesterday and told them to git pull and explore :)
Ow. Alright, it'll probably take a hour or two - keep an eye out for the push
they have a huge mountain of concepts they're climbing, so trying to make things as absolutely simple as possible. only thing I didn't do for the converter team was drop in the Khronos gltf test cases they're going to conform against, but that'll need to go somewhere too eventually.
it's technically test infrastructure, so probably something like src/gcv/tests/gltf
If we can come up with a few simple directory naming patterns we can put in the repository regression tester and similar tools so they know to treat the contents of those dirs differently, and then use those reliably, that would probably work.
@Sean were you deliberately leaving some whitespace issues for them to find and fix?
I like ext, short and sweet, would parallel src/other/ext and could be managed similarly. you have a nice simple setup there, so lets run with it.
starseeker said:
Sean were you deliberately leaving some whitespace issues for them to find and fix?
Not find and fix, no - the instruction was simply that it's working reference code. It "works" in the sense that it compiles and they can directly see how it was derived from the loader example in tinygltf, but it doesn't raytrace and isn't structured.
their task is to make a gcv plugin, so src/conv/gltf will probably get deleted when they get theirs working
OK, just making sure I wasn't blowing away a test case ;-)
that whole dir was a compilable reference for them, they may choose to start with it as a base -- and if they do, then we'd have a talk about the code conventions being wrong. I had in mind to pretty-print format the code, but was keeping it as-is for now just so they can line-compare with where it came from
but yeah, I don't think formatting will make or break their understanding
half of them use VS Code which does NOT like our style by default.. indentation is all screwed up
We never did get around to the astyle reformat, did we
nope, with good reason -- I think about that often :)
would invalidate every outstanding patch and code we have pretty hard... I'd at least want to try and merge as much as possible first
OK, I (more or less) put it back - I'm not sure what to do about the static analyzer though, other than bump the count back up
I got a few in the main converter file, but IIRC some of the complaints are from the stb headers.
I'll know in a bit... re-running now
what's it complaining about?
way to exclude it perhaps since it's not production?
I don't really know of a good way to tell clang to ignore code coming in from particular headers, unfortunately
Dead store Dead assignment conv/gltf/tinygltf/stb_image.h stbi__tga_load 5708 1
Dead store Dead increment conv/gltf/tinygltf/stb_image.h stbi__high_bit 5079 1
Dead store Dead initialization conv/gltf/tinygltf/stb_image.h stbi__tga_load 5531 1
Dead store Dead initialization conv/gltf/tinygltf/stb_image.h stbi__parse_png_file 4890 1
Dead store Dead initialization conv/gltf/tinygltf/stb_image.h stbi__tga_load 5530 1
Dead store Dead nested assignment conv/gltf/tinygltf/stb_image.h stbi__tga_load 5709 1
Dead store Dead nested assignment conv/gltf/tinygltf/stb_image.h stbi__zexpand 4015 1
Dead store Dead nested assignment conv/gltf/tinygltf/stb_image.h stbi__tga_load 5708 1
Dead store Dead nested assignment conv/gltf/tinygltf/stb_image.h stbi__tga_load 5709 1
Dead store Dead nested assignment conv/gltf/tinygltf/stb_image.h stbi__tga_load 5708 1
Unix API Allocator sizeof operand mismatch conv/gltf/tinygltf/stb_image_write.h stbi_zlib_compress 875 1
Can be cleared easily enough - I already did so in fact - but then we're back to not being vanilla
If this turns out to be production code I'm OK with that, but since we're not sure this is the answer...
I'll just bump the expected count for now.
Yeah, I was giving them this week to look it over, and then recommend they implement what they want to do from scratch (using it as a reference or whatever, but do so cleanly).
could exclude src/conv/gltf/gltf-g.c ? just leave a comment so we can revisit in 3 months
it's kind of funny.. stb_image.h is a header-only library that implements a whole slew of image file formats, used by tinygltf which is also header only
I'm not really set up to do that any more, unfortunately - I simplified the analyzer script when I got the bug count down, so I'm no longer calling out very many individual targets.
okay
Bumping the count is the simplest thing for now, and if we use 'em for real we'll have to try and clean 'em up
I think they trigger a few Coverity issues as well, for that matter
(I didn't shift it into an ext subdir yet, so your instructions should be good again.)
You know, with the new ext build setup I should probably revisit bullet - if I'm using their build system as-is I might not have the problems we had before.
Last updated: Jan 09 2025 at 00:46 UTC