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

The files target property: Add support for directories #1053

Merged
merged 6 commits into from
Mar 26, 2022

Conversation

Soroosh129
Copy link
Contributor

This adds support for including entire directories in the files target property (e.g., files: ["/etc"]).

I found this to be very convenient. Imagine a game that requires a number of images that are located in a folder.
It would be convenient to be able to use files: ["images"] instead of listing each image file one by one.

@Soroosh129 Soroosh129 requested review from edwardalee and lhstrh March 18, 2022 02:34
Copy link
Collaborator

@edwardalee edwardalee left a comment

Choose a reason for hiding this comment

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

LGTM! Useful feature. Let's merge.

org.lflang/src/org/lflang/generator/c/CUtil.java Outdated Show resolved Hide resolved
Co-authored-by: Edward A. Lee <[email protected]>
@Soroosh129 Soroosh129 merged commit 72679ea into master Mar 26, 2022
@Soroosh129 Soroosh129 deleted the files-supports-directory branch March 26, 2022 15:16
Copy link
Member

@lhstrh lhstrh left a comment

Choose a reason for hiding this comment

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

I think the added feature makes sense, but I had some comments in the pipeline that I didn't get to share before the PR was merged.

* @param dstDir Where the file or directory should be placed.
* @return The name of the file or directory in destinationDirectory or an empty string on failure.
*/
public static String copyFileOrResource(String fileName, Path srcDir,
Copy link
Member

Choose a reason for hiding this comment

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

I think it would be better to rename fileName to fileOrDir.

// because it is the only one currently capable of handling asynchronous events.
if (!targetConfig.threading) {
if (!targetConfig.threading && !targetConfig.setByUser.contains(TargetProperty.THREADING)) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm a little confused about this change. What does it do? I seems entirely unrelated to the PR.

public static String copyFileOrResource(String fileName, Path srcDir,
Path dstDir) {
// Try to copy the file or directory from the file system.
Path file = findFileOrDirectory(fileName, srcDir);
Copy link
Member

Choose a reason for hiding this comment

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

I would rename file to path here.

}
}

String filenameWithoutPath = fileName;
Copy link
Member

Choose a reason for hiding this comment

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

The following takes the tail of a path (e.g., foo/bar/baz.lf yields baz.lf; foo/bar yields bar) and just looks for it on the class path. This doesn't seem right to me. I don't think there are any tests for this, and I think the FIXME below alludes to this. I realize this FIXME preexists this PR, but I think we should fix and not ignore it.

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.

3 participants