search

sheredom / subprocess.h

🐜 single header process launching solution for C and C++
The Unlicense
1.12k stars 97 forks source link

naming conflict with windows process.h #4

Closed xoorath closed 4 years ago

xoorath commented 6 years ago

Hey,

I know "process.h" is a really compelling name, but for me at least having such a generic name is a bit of a pain. Including this file it conflicts with: c:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\process.h, which vs2017 picks up first when including process.h

This wouldn't be a problem if I were just adding it to my project normally, as I could just put it in a folder, but since I'm using a package manager and grab your repo - my only easy option is to add your repository as an include directory. Because you don't have a dist/ or include/ directory or anything like that, I don't have a way to be selective about including the exact file I want to.

I'm going to work around this by skipping the package manager for this dependency, but I'd like to make the suggestion that maybe you could have some branded name? Like Sean Barrett's STB? Would be pretty handy for avoiding conflicts!

my 2 cents. thanks 👍

sheredom commented 6 years ago

First off, thanks for raising this issue!

I was previously pinged about this on twitter https://twitter.com/rygorous/status/946331558885101568 too, and tbh I've not got a really solid view on what to do yet.

I'm torn by using something like stb_ because it'd probably mean I'd have to go through all my previous libraries to do renames (at least the purist in me thinks I'd have to!).

Would subprocess.h be acceptable?

xoorath commented 6 years ago

I'd have to try it to be sure it works out for msvc, but also just having the header inside some directory (include/process.h or dist/process.h or process.h/process.h) would also do the trick.

Really the problem is on the side of microsoft for not having their header be in WinSdk10/process.h in my opinion, but it's a problem I don't soon expect to convince them to fix.

The solution of changing it to subprocess.h would be fine for me, but I wouldn't love the idea of a very trivial issue I'm having shape the identity of your library. You've already got a popular post out about it with the current name, and it would be harder for folks to find that don't know you and your work directly, but just heard about this library.

As mentioned I have a workaround, but if I were you I'd opt for putting it in a folder, or doing something like stb. It might actually just be a benefit to you to start building an identity for your single header libraries in this way? not sure if you would care about that, but might be a nice way to bring them together.

sheredom commented 6 years ago

It might actually just be a benefit to you to start building an identity for your single header libraries in this way?

Just to be clear - is this a suggestion for doing a mono-repo of my headers?

xoorath commented 6 years ago

@sheredom Nah, just prefixing file/lib names is all I meant.

For me I prefix small library projects with xo. Should they ever become popular like yours are, it would be easy to recognize my work and has fringe benefits like filenames being almost certainly unique.

I don't think I'd have a preference as a user on how you deliver your libraries (one repo or multiple). If I had to lean one way, I like the way you do it currently so I don't get extra files I'm not as interested in.

cdwfs commented 6 years ago

me-too to pretty much everything @xoorath said. Manually moving/renaming the file in my project is obviously the easiest workaround, but it's so much nicer when things just work out of the box, isn't it? My ideal flow as a client would be:

  1. Clone into my project's third_party folder
  2. Add third_party//include to my project's include list
  3. #include <third-party-lib.h> in my source
  4. Enjoy a high-gravity barrel-aged ale

Instead I'm adding the main third_party folder to my include list, and #include'ing <process.h/process.h>, but that has its own drawbacks.

I'd have to try it to be sure it works out for msvc, but also just having the header inside some directory (include/process.h or dist/process.h or process.h/process.h) would also do the trick.

I assume the idea is that you'd #include <directory-name/process.h> from your source to distinguish it from the Windows process.h? If so, I'd vote for a more unique directory name than "include" or "dist" -- "process.h" would work, but seems redundant. I'd vote for just sucking it up and adding a prefix to the filename. If you're unhappy with "nph"...well, take it from me, changing your middle name is much easier than one might think :)

sheredom commented 6 years ago

Thanks for all the comments - I'm still internally debating what to call this thing (tis hard when you hate your own name!). This issue will be resolved though, don't fret!