Skip to content

Conversation

kenmo-pb
Copy link
Contributor

@kenmo-pb kenmo-pb commented Aug 1, 2025

Minor Issue: Compiling will fail with an unintuitive error (linker error) if the destination folder does not exist. This is more common an issue when using a Project and Build All Targets rather than Create Executable and manually browsing to a destination.

Proposed Solution: Right before compiling, automatically create the destination folder, including its parent folders, recursively if necessary. I think this is a reasonable expected behavior.

More Context: When working on a large cross-platform project, you might organize your build targets into nested subfolders, for example <project>/build/demo/windows/x86/MyApp.exe or <project>/build/full/linux/x64/MyApp. Build All will fail if these subfolders don't exist. Manually preparing the output folder structures on several systems can be annoying... Before you ask "Why can't you just copy the folder structure around?" If you're working with Git, Git does not preserve folders which contain no files or nested files! So any time you git clone or git pull or even git archive --format zip, it does not carry along empty folder structures. (Also, it's common to .gitignore your build output folder anyway.)

Thanks for considering.

ProcedureReturn #True

Case -1 ; does not exist - create it
CreateDirectoryRecursive(ResolveRelativePath(Directory$ + #Separator + "..", ""))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This use of ResolveRelativePath() does not fit how the procedure is documented above: The first argument is supposed to be a full path (no "..") and only the second argument is supposed to be relative.

So ResolveRelativePath(Directory$, ".." + #Separator) looks more right.

Then you also need to change the abort condition for the recursion, as the procedure returns the second argument on failure.

@kenmo-pb kenmo-pb force-pushed the recursive-build-folder branch from 5954e4f to 10246ae Compare September 3, 2025 02:14
@kenmo-pb kenmo-pb force-pushed the recursive-build-folder branch from 10246ae to 44e5d4d Compare September 3, 2025 02:26
@kenmo-pb
Copy link
Contributor Author

kenmo-pb commented Sep 3, 2025

@t-harter True, that's not how ResolveRelativePath() is intended to be used, I was trying to utilize existing procedures instead of adding a new GetParentPath() or similar.

In closer review of FileSystem.pb, I realize UniqueFilename() is a better choice, in fact that's what ResolveRelativePath() is using to process ".." in a path. Do you agree?

I just pushed a new version of the commit. I also check the result now for empty string, to avoid potential CreateDirectoryRecursive("") call.

@t-harter t-harter merged commit 9a4700a into fantaisie-software:devel Sep 8, 2025
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

Successfully merging this pull request may close these issues.

2 participants