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

packaging: Rename pkg to build-aux #551

Closed
wants to merge 1 commit into from
Closed

Conversation

ppd
Copy link
Member

@ppd ppd commented Feb 12, 2020

Snapcraft 3.3 introduced support for snap directories
at build-aux/snap instead of only at root level.

Take advantage of this by renaming pkg/ to build-aux/
which enables us to drop the hacky indirection of snap/build.sh,
resulting in less complexity and a cleaner directory layout.

When I created the original snap packaging, I overlooked this feature which had been recently introduced. It's a neat opportunity to simplify stuff but it also moves the flatpak packaging. Not strictly necessary but still a very good idea, I feel.

Note: build-aux for packaging/building is very common within the GNOME ecosystem

Snapcraft 3.3 introduced support for snap directories
at build-aux/snap instead of only at root level.

Take advantage of this by renaming pkg/ to build-aux/
which enables us to drop the hacky indirection of snap/build.sh,
resulting in less complexity and a cleaner directory layout.
@whitequark
Copy link
Contributor

I quite dislike this change. I don't think that a single packaging mechanism should dictate the directory layout in a repository of a cross-platform application.

@whitequark
Copy link
Contributor

It is also not even a good name; I use build-* directories to organize builds for a variety of platforms and toolchains, like build-mingw32 and so on, as you can see in the gitignore file. This would make rm -rf build* unusable.

@ppd
Copy link
Member Author

ppd commented Feb 12, 2020

I like pkg better too, by a lot. It's just a thing I learned about snapcraft an hour ago, and so I felt it was sensible to at least discuss it.

@whitequark
Copy link
Contributor

I think your original approach works perfectly fine.

@whitequark whitequark closed this Feb 12, 2020
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.

None yet

2 participants