generate and install .pc file

[andy5995]

closes #1

My editor stripped off some trailing whitespace which makes the diff a bit longer than it needs to be, but...

Primary changes are on L62 and 109-113

No version is set yet. I can add one or you can do that later.

The .pc file that gets generated looks like this:

prefix="/usr/local"
exec_prefix="${prefix}"
libdir="${prefix}/lib"
includedir="${prefix}/include"

Name: portmidi
Description: Cross-Platform MIDI IO
Version: 
Cflags: -I${includedir}
Libs: -L${libdir} -lportmidi

[Be-ing]

I have already done this in my CMake rewrite and will make a PR for that soon.

[Be-ing]

will make a PR for that soon

Here it is: #3

[andy5995]

Thanks for the FYI @rbdannenberg . Cheers!

[andy5995]

@rbdannenberg Related to what I said in https://github.com/PortMidi/portmidi/pull/3#issuecomment-998489897

No problems for me here when you merged in master, because it wasn't near code I had changed. Normally what you'd want to do in this case is just ask the submitter to rebase. Then my branch (and PR) is only altered by the submitter which prevents work from overlapping. Often, rebasing isn't even necessary. It's primarily necessary to make sure that any new changes won't break the exiting code base basically.

For the purposes of this PR, a rebase wouldn't even be necessary for those changes you made on L6 and L7. It basically boils down to the fact that a PR doesn't have to "include" any changes that were made to master. The differences are "merged" in when the PR is merged. But as I said above, sometimes changes to master should be included, and that's when rebasing is most suitable.

[andy5995]

@rbdannenberg P.S. I've found rebasing to be pretty confusing, and really I learned about it through first-hand practice on non-master branches (not by reading about it). And really there should never be a need to rebase while on the master branch. It's primarily meant for integrating changes from master.

[rbdannenberg]

@andy5995 I just heard here that the configure file generation is not working well when PortMidi is embedded in another project. I think the suggested changes should be made, but since I just approved and merged your changes on this, I wanted to give you a chance to comment or try them out. I think the change to configure_file(portmidi.pc.in portmidi.pc @ONLY) seems best.

Also, I think I should take out BUILD_SHARED_LIBS as an option and put in PM_BUILD_SHARED_LIBS specific to PortMidi but controlled by BUILD_SHARED_LIBS if it is specified. It seems like this will add a lot of conditional code, but maybe I can find a clean way to do it.

[Be-ing]

Also, I think I should take out BUILD_SHARED_LIBS as an option and put in PM_BUILD_SHARED_LIBS specific to PortMidi but controlled by BUILD_SHARED_LIBS if it is specified. It seems like this will add a lot of conditional code, but maybe I can find a clean way to do it.

Please do not do this. Use the built in CMake features, do not hack around them and force downstreams to learn idiosyncratic options for every package.

[andy5995]

@rbdannenberg, I'll agree with @Be-ing . Here's how I see it, from what I've observed and learned by playing lots of different projects over the last few years. Your project is an independent library. It should build a static and shared lib by default, install them, the headers, and the .pc file when install is requested.

That's all what typically gets installed when a library is packaged by distro maintainers.

Maybe @ddevault would be kind enough to weigh in on this...

And you should be able to freely use variables based on the name of your project.

I'll reply to your other question in https://github.com/sonoro1234/Lua2SC/issues/6

[ddevault]

I lack context for this specific project, but in general I would agree that you should strive to use standard build configurations and not to get too clever with your build system. Building and installing a static and shared library, headers, and a pc file is the correct approach. I will note, however, that cmake is probably one of the worst build systems available today, and you're going to fight it tooth and nail to accomplish pretty much everything - upstream or downstream.

[andy5995]

that cmake is probably one of the worst build systems available today, and you're going to fight it tooth and nail to accomplish pretty much everything - upstream or downstream.

Thanks @ddevault .I can't completely agree with that, but I can say I've had quite a lot of trouble with cmake myself, and use @mesonbuild for all my projects now ;)

[rbdannenberg]

I'm happy to leave BUILD_SHARED_LIBS as is. This comment suggested it's a problem or at least not a good practice, but unless there's a really strong case for changing, I'll assume BUILD_SHARED_LIBS is the right thing. Thanks for quick feedback on this.