[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Sv: Sv: TODO

>Good. But we should first set up the complete thing locally (ftping or
>mailing the tar.gz's around) until we know it's a good layout - before we
>even touch CVS.
>And some "CVS access guide" (esp. concerning how and when adding
>directories to CVS is allowed) could be useful as well.

>>>(2) Rewrite the build system (which is a little mess now)
>>I don't know anything about that, so I can't comment.
>Well, you *do* know ;)
>What do we need to make it easy to build the library under Win32? A set of
>makefiles, a project file or something else?
VC++ relies on VC++ specific project-files. These can only be built by VC++.
VC++ can also read makefiles, but not the kind PPlay uses right now. The by
far most convinient thing for VC++ developers is to have a VC++ workspace
and project file.

I don't know the situation for other Win32 compilers.

>>>(3) Clean up the core PPlay headers (which are rather messy now)
>>Oh yeah, that reminds me: either each header should only include the
>>PenguinPlay.h header, -OR- one of the project-specific headers, since all
>>the project-specific headers also include PenguinPlay.h (atleast
>>PenguinFile.h does).
>Doesn't matter. That's what include guards are for. And including both
>PenguinPlay.h and <sublib>.h is IMHO clearer (it's bad behavior to rely on
>some header including another one).
It is bad on the time it takes to build a project if each and every file
includes the same header twice (which is in effect what is happening).

Not that big a deal, though.

That reminds me, would it be ok to include a VC++-specific pragma in each
very-frequently-used-header? (this pragma would of course be excluded by the
precompiler if the preprocessor symbols that signify that VC++ is the
compiler is being used is not defined) The pragma I'm thinking about is

#pragma once

It means that VC++ will know that a specific file should only be opened
once, even if its included several times. Its faster than inclusion guards.

>>That, or IMHO the project-specific headers should not include
>But usually they need the things declared in there (e.g. data types).
Yes, that's why its a bad solution. Creates dependencies on inclusion order.