Rok Mandeljc rok.mandeljc@email.si writes:
Hey everyone,
I finally found some time to organise my dmusic work of last two months in useful patch. Dmusic is now DX9 compatible, we have almost fully implemented (but not working :( )
The dmusic_common.c thing is wrong, you can't use the same source file in multiple dlls, this won't build properly. Also you should not include private header files from other dlls, if definitions really have to be shared they should be in a common header somewhere in include/ or include/wine, though in most cases you should be able to avoid that.
The dmusic_common.c thing is wrong, you can't use the same source file in multiple dlls, this won't build properly. Also you should not include private header files from other dlls, if definitions really have to be shared they should be in a common header somewhere in include/ or include/wine, though in most cases you should be able to avoid that.
I can't see how sharing dmusic_common.c would mess up building (it builds and works fine for me), but then again you have more experiences on this matter. Do you have any suggestions what should I do about it?
And I believe shared private header you had in mind was dmusic_common.h; I didn't know it was forbidden to do it since you didn't say anything when I included dmusic_private.h in dmime_private.h last time.
Anyway, dmusic_common.c and dmusic_common.h are there primarily for generic IDirectMusicObject functions; it's really easier to implement it that way and it simplifies code maintenaince.
Rok Mandeljc rok.mandeljc@email.si writes:
I can't see how sharing dmusic_common.c would mess up building (it builds and works fine for me), but then again you have more experiences on this matter. Do you have any suggestions what should I do about it?
It breaks parallel makes and dll separation. Dlls should not depend on one other this way. The best way is to duplicate the few things you need in each dll.
And I believe shared private header you had in mind was dmusic_common.h; I didn't know it was forbidden to do it since you didn't say anything when I included dmusic_private.h in dmime_private.h last time.
I missed it when reading the patch; you may notice I have fixed it since then...
Alexandre Julliard wrote:
It breaks parallel makes and dll separation. Dlls should not depend on one other this way. The best way is to duplicate the few things you need in each dll.
And what if there are not a few things, but many?
(Not much use looking for duplicated code if patches will not be accepted.)
Is there no other way of sharing code? Is using include files with code in them acceptable?
Jakob
Jakob Eriksson jakov@vmlinux.org writes:
And what if there are not a few things, but many?
(Not much use looking for duplicated code if patches will not be accepted.)
Is there no other way of sharing code? Is using include files with code in them acceptable?
Usually not. The point is that if a lot of code needs to be shared, then there is normally a way to do it with the exported APIs. If there's no way to do that, then it's probably a sign that we are not implementing it the right way.
It breaks parallel makes and dll separation. Dlls should not depend on one other this way. The best way is to duplicate the few things you need in each dll.
OK, guess you're right... but just as a thought, would it make any difference if I made symlinks from dmusic/dmusic_common.c to others and then list them as "local" sources (can diff & cvs hadle symlinks)? Or just copying dmusic_common.c to all dm* folders and then include them locally? (as for dmusic_common.h, there won't be much need for this one then and I could put its contents in dm*_private.h).
-
Alexandre Julliard -
Jakob Eriksson -
Rok Mandeljc