This is _relatively_ minor, but: There's a long-standing convention --
laziness, really -- in the CMake world, of doing out-of-source builds in a
directory named `build`, often located (for convenience) in the top level of
the repo dir. `rpmbuild` living in `/build` screws with that convention.
It's far from insurmountable (I just built everything in a directory named
`_build`, for my current test run), but still it's bound to be confusing, and
dumping autotools (#2232) gives us an opportunity to cleanly un-screw with it.
Let me just say that I'm willing to do the work of addressing this. I know
CMake well and am confident I can talk it into whatever we decide. I just don't
want to put a lot of work into a PR that won't be merged, so I thought it best
to first discuss an approach. (_If any_, since not addressing it is certainly
an option.)
#### Non-solutions
* Simply rename `build` to `rpmbuild`. (Conflicts with output binary name, in
the build dir.)
#### Possible solutions
In no particular order, since I jotted them down as they came to me.
1. Create a `src/` dir, and move the top-level `.c` files, `build`,
`fileattrs`, `misc`, `rpmio`, and `sign` into that dir.
1. Rename `build` to `rpmbuild`, **and** have it output the `rpmbuild` binary
target _inside_ that directory, rather than at the top level of the builddir.
(That's also somewhat more in keeping with CMake conventions, though I think
we'd then want to have the rest of the binaries do the same, for consistency.
Which makes it a bit of work in terms of both build tooling and subsequent
packaging/testing.)
1. Rename `build` to `rpmbuild`, and have all the executable targets (or, all
targets?) output into a `bin/` directory inside the build dir. (Same caveats as
previous.)
1. Move `build` to `lib/rpmbuild`, since it's **really** the source to
`librpmbuild`. (Probably also `rpmio` => `lib/rpmio`, and `sign` =>
`lib/rpmsign`, again for consistency.)
1. Rename `build` to `librpmbuild`, `rpmio` to `librpmio`, `sign` to
`librpmsign`, and -- say it with me, "for consistency" -- `lib` to `librpm`.
1. ???
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2250
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
