Stream: brlcad

Topic: bext


view this post on Zulip starseeker (Feb 17 2024 at 02:33):

For those experimenting with bext, the latest main will now clone and build its own copy of bext as part of the configure stage if a BRLCAD_EXT_DIR location isn't supplied.

view this post on Zulip starseeker (Aug 02 2024 at 15:10):

@Sean If you're going to remove the src/bext submodule, be sure to update the docs and remove the build logic that checks for it

view this post on Zulip Sean (Aug 02 2024 at 20:26):

@starseeker Ooops, I just saw an empty dir and thought it was leftover. Where does it check for it? Why does it need to be there empty?

view this post on Zulip starseeker (Aug 02 2024 at 22:26):

https://github.com/BRL-CAD/brlcad/blob/main/misc/CMake/BRLCAD_EXT_Setup.cmake#L50

view this post on Zulip starseeker (Aug 02 2024 at 22:26):

That's how unpopulated submodules in git work, AFAIK - a shallow bext clone is like that, as well

view this post on Zulip Sean (Aug 03 2024 at 06:02):

okay, so it's currently looking for it that way.. and that possibly explains some other issues I kept running into.

bit unexpected to have running something in the build dir affect the source tree by default. I assumed it was cloning into the build dir. Invoking action was a build action, so it probably shouldn't be touching the source dir.

Any reason it couldn't just be an external project add like bext is doing? That way, the clone rule will live in the build logic and the files will be in the build tree.

view this post on Zulip starseeker (Aug 03 2024 at 13:16):

If the cmake configure does a clone, it is doing it in the build dir. The submodule in src/ was to allow a single git clone command to download everything needed for any BRL-CAD build config, in a single shot

view this post on Zulip starseeker (Aug 03 2024 at 13:17):

If the user clones BRL-CAD with a git clone --recursive, then (and only then) src/bext is populated. Otherwise, everything happens in the build directory

view this post on Zulip Sean (Aug 03 2024 at 15:36):

Ahh, okay, so then it doesn't explain some other issues I kept running into...

view this post on Zulip Sean (Aug 03 2024 at 15:38):

Weird. I never did the recursive, but the auto kept giving me trouble. I've since switched to a manual build of bext because it would be broken after any change to a submodule (different reasons iirc).

view this post on Zulip Sean (Aug 03 2024 at 15:39):

So then sounds like there's three ways -- a recursive clone into src, an auto clone into builddir, or manual BRLCAD_EXT_DIR

view this post on Zulip starseeker (Aug 03 2024 at 17:50):

Correct.

view this post on Zulip starseeker (Aug 03 2024 at 17:51):

The first is intended for the "I don't care about disk space, make sure I've got everything I'll ever need" case. The second is the "only build what I need for this config of BRL-CAD" case. The third is the "I'm going to be compiling this sucker a lot, I don't want to keep rebuilding this" case.

view this post on Zulip starseeker (Aug 06 2024 at 18:47):

Regarding the question of automatically responding to updated sources from git updates... My best guess is it would take some sort of custom UPDATE_COMMAND: https://cmake.org/cmake/help/latest/module/ExternalProject.html#update-step-options

view this post on Zulip starseeker (Aug 06 2024 at 18:54):

Sticking rsync -a --delete into the Itcl ExternalProject_Add as an UPDATE_COMMAND results in rebuilding every time, so it appears to be triggering as expected - the trick would be to conditionally trigger based on a change in the original sources, rather than just doing it blindly. Probably a CMake script could do it...

view this post on Zulip Sean (Aug 06 2024 at 22:18):

@starseeker food for thought, thanks for checking. Might be a little more hairy if updates involve new patches also -- would probably need to catch any change inside the dependency subdir, invalidate it, and proceed as before (ideally). Not sure it's worth the extra logic though if that'd need to get injected into any places outside update_command (e.g., patching).

view this post on Zulip Sean (Aug 06 2024 at 22:18):

On a mildly point -- the itcl header patch is no bueno. There's no Tcl vars accessible to Itcl at that point, so the vars are invalid/empty.

view this post on Zulip starseeker (Aug 07 2024 at 00:54):

The patch file itself, or the associated CMake logic?

view this post on Zulip starseeker (Aug 07 2024 at 00:55):

I'm testing some ideas now - you have a point that things will get hairy if we all start piling into updating dependencies. I initially shied away from the added complexity in the initial work, but I'll see if I can find a reasonable solution

view this post on Zulip starseeker (Aug 07 2024 at 01:05):

Oh, right gotcha - the Itcl build is doing find_package for Tcl, but the parent isn't

view this post on Zulip starseeker (Aug 07 2024 at 01:05):

Duh.

view this post on Zulip Sean (Aug 26 2024 at 14:11):

This project reminded me of bext taken to the extreme... https://github.com/fosslinux/live-bootstrap/tree/master

They fully bootstrap a modern OS starting with nothing but a few hex numbers, progressing through to building tools that build the tools that build the tools, etc. Full steps here: https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst

view this post on Zulip starseeker (Aug 27 2024 at 00:05):

Cool!

view this post on Zulip starseeker (Aug 27 2024 at 00:25):

That reminds me a little of some of my ideas for hobby projects from ten years+ ago... although I never thought about taking it to that extreme. I must salute their awesome craziness :-)


Last updated: Oct 09 2024 at 00:44 UTC