starseeker (Feb 17 2024 at 02:33): 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.
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
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?
starseeker (Aug 02 2024 at 22:26):https://github.com/BRL-CAD/brlcad/blob/main/misc/CMake/BRLCAD_EXT_Setup.cmake#L50
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
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.
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
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
Sean (Aug 03 2024 at 15:36):Ahh, okay, so then it doesn't explain some other issues I kept running into...
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).
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
starseeker (Aug 03 2024 at 17:50):Correct.
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.
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
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...
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).
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.
starseeker (Aug 07 2024 at 00:54):The patch file itself, or the associated CMake logic?
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
starseeker (Aug 07 2024 at 01:05):Oh, right gotcha - the Itcl build is doing find_package for Tcl, but the parent isn't
starseeker (Aug 07 2024 at 01:05):Duh.
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
starseeker (Aug 27 2024 at 00:05):Cool!
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 :-)
Daniel Rossberg (Oct 20 2024 at 16:41):Is there a best practice for how to work with it? E.g., how to set BRLCAD_EXT_SOURCE_DIR and BRLCAD_EXT_BUILD_DIRBRLCAD_EXT_BUILD_DIR? I tried to set them in the CMake GUI. Then, it first complained about the not existing first directory. I thought, it will be created automatically. Next, it threw an error while trying to use the default external build directory.
Obviously, I did something wrong. What is best practice for doing this?
starseeker (Oct 21 2024 at 13:07):-DBRLCAD_EXT_DIR=/home/user/bext_output is usually how I set things up for a pre-existing BEXT build.
starseeker (Oct 21 2024 at 13:07):If you don't have a pre-existing bext build, you shouldn't need to do anything - configure should take care of things.
starseeker (Oct 21 2024 at 13:10):You shouldn't need to delve into the lower level variables unless you're (say) trying to have BRL-CAD's configure manage a build from a pre-existing bext source tree clone. That'd be when to set BRLCAD_EXT_SOURCE_DIR
starseeker (Oct 21 2024 at 13:13):I don't think there are too many cases where you'd want to override BRLCAD_EXT_BUILD_DIR - about the only thing that comes to mind is if for some reason you're having to do a BRL-CAD build on a small or almost full disk and you want to put the bext build outputs somewhere else, but still want the CMake configure to manage the build.
starseeker (Oct 21 2024 at 13:14):https://github.com/BRL-CAD/bext?tab=readme-ov-file#using-the-build-outputs-with-brl-cad
Daniel Rossberg (Oct 21 2024 at 13:27):I was testing with different versions and branches, e.g. devel_k-g and main. There, the bext build was the most time consuming part (over an hour each with hotel WiFi). That's why I would like to have one build for all.
Daniel Rossberg (Oct 21 2024 at 13:54):It looks like BRLCAD_EXT_DIR isn't memorized. What I did:
:right: Until here, it works well. CMake runs some seconds and prepares the build without cloning bext.
Now, I started the CMake GUI to adjust the install directory. After pressing configure, it started cloning the bext stuff again.
starseeker (Oct 21 2024 at 14:19):Ah, I see. You're right, it's not being written to the cache and a repeat configure forgets about it. Does https://github.com/BRL-CAD/brlcad/commit/0144bdd6edc77a7c722c9269343ccc3398213ded do what you need?
Daniel Rossberg (Oct 21 2024 at 14:32)::+1: Looks good.
CMake was fast, now I'm running make.
starseeker (Oct 22 2024 at 20:09):@Sean I'm setting up in a branch to make tinygltf a bext component rather than embedded in BRL-CAD - let me know when a good time to merge would be.
Sean (Nov 01 2024 at 15:29):@starseeker go for it
claymonkey (Nov 23 2024 at 00:16):I tried using (git clone --recurse-submodules https://github.com/BRL-CAD/brlcad) to obtain all the files, but I got the following error while compiling the bext file using
(
f279e83ff4a41e294eeef597a8b3ba3.png
).I didn't find the line "verbose_add_subdirectory" in it, and the files "(ProjectName)(project)" and "(cmake_minimum_required(VERSION 3.31))" don't exist.
e6dc2720df8baefdaea1f4c41da55bd.png
Last updated: Jan 07 2025 at 00:46 UTC