Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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 <eal@eecs.berkeley.edu>
@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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants