I'm working on a little project using PDCurses/NCurses and panel.h. While the project compiles/runs fine on Linux with NCurses, using PDCurses on Windows I have a bit of a problem. The precompiled DLLs provided for Windows don't include the panel library, and when I attempt to compile the libraries myself, they don't work (possibly due to my lack of experience with Windows libs...) If one of the developers could possibly supply a pre-built package that includes panel, or if someone could give me some instructions on how to compile PDCurses with MSVC++ 2005 Express that I could distribute with my source code, I would greatly appreciate it.
VC 2005 Express is a pain. I wrote a bit about it here:
It's not as bad now, but the third paragraph in particular still applies.
Now, you've caught me at an interesting moment. I knew this was a problem, and I was just on the verge of posting to the mailing list about something I've been agonizing about for a while: the idea of merging the panel library into the curses library. See, the panel library has never been DLL-ized. But it's too tiny to really make sense as a DLL of its own. So why not merge it into the main library? It would solve several other problems as well. However, it would mean that it would break for everyone out there who's got "-lpanel" in their makefiles. So, I've hesitated. I even thought about including an empty, dummy panel library to get around the problem; but that's just too ugly.
Anyway, I implemented it, as a test (both ways), and it worked fine. It's just a question of deciding to do it. I'm 90% there, but I'm just not sure. Opinions?
> Read and respond to this message at:
> By: wmcbrine
> VC 2005 Express is a pain. I wrote a bit about it here:
> It's not as bad now, but the third paragraph in particular still applies.
Wow, I remember using the _CRT_SECURE_NO_DEPRECATE solution. I also
recall that they had some very specific instructions about the SDK, for VC 2005
Express. That seemed to work ok for me. I've not tried the cmdline tools though,
and I'm not surprised there were more surprises.
> Now, you've caught me at an interesting moment. I knew this was a problem, and
> I was just on the verge of posting to the mailing list about something I've
> been agonizing about for a while: the idea of merging the panel library into
> the curses library. See, the panel library has never been DLL-ized. But it's
> too tiny to really make sense as a DLL of its own. So why not merge it into
> the main library? It would solve several other problems as well. However, it
> would mean that it would break for everyone out there who's got "-lpanel" in
> their makefiles. So, I've hesitated. I even thought about including an empty,
> dummy panel library to get around the problem; but that's just too ugly.
I would agree that it would make more sense to include the panel
code in the same DLL. Why load a 2nd DLL for a small amount of code?
As far as building code under Windows, the Makefiles are going to have to make
some distinctions for that platform anyway, and so one more distinction can
easily be made to modify pdcurses linking (this doesn't address existing
projects mind you, but hey- things do change). If the project
is under cygwin and uses autoconf/automake, it can easily configure for this.
For *NIX platforms though, I think I would keep it divided among traditional lines.
That would keep the old curses, ncurses and pdcurses a little more interchangable
(like on HPUX for example).
> Anyway, I implemented it, as a test (both ways), and it worked fine. It's just
> a question of deciding to do it. I'm 90% there, but I'm just not sure. Opinions?
For windows, I suggest that you combine it as proposed.
Yeah, it was the existing projects that I was worried about. And the X11 library already uses "libXCurses" and "libXpanel", so it's not exactly interchangeable with other curses now. Anyway, I realized that I can symlink libXpanel to libXCurses, and resolve the problem for that platform. (There's no penalty for linking the same library twice.)
For Windows, I can't symlink, but copying pdcurses.lib to panel.lib and linking it twice works there, too. So I guess I could recommend that to anyone who didn't want to edit their makefiles. :)
I'm still concerned that it will break configure scripts, etc., that might only look for panel.lib, and abort or drop panel functionality if they don't find it. Of course, my biggest concern is that people won't read the documentation (do they ever?), will see the build break, and just think PDCurses is broken. Then too, there'll be a certain percentage of people who want to retain compatibility with older versions, and they'll be annoyed by the change.
Well, despite my misgivings, I've tentatively committed the change to CVS, so people can try it out.
...and now it's in 3.2, with the pre-built DLLs in the file releases.
I just have pdcurses.lib/.a copied to panel.lib/.a when built, so those who don't read the docs shouldn't notice a difference. :)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.