There seems to be a mismatch between the following two includes files:
AAFFileKinds.h
AAFMetaDictionary.h
They are different in ref-impl/include and AAFi686LinuxSDK/g++/include
The versions in AAFi686LinuxSDK/g++/include don't seem to have the latest changes. So the question is: should there even be CVS elements in the AAF*SDK directories, or should these only be populated when you build the toolkit for a particular platform?
JF
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with your observation. I have verified that these files do get updated with the versions from ref-impl/include with a make install.
At the very least, I will update the version in AAF*SDK before we do the release. Perhaps they shouldn't be there at all, as you suggest. I have a feeling they are copied to the platform-specific directories due to a detail with MSVC project files. Anyone know the history here?
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason they are checked in is to avoid having to do a cd ./meta; make before doing a make all. It could be argued that the makefile in ./meta should incorporate distribution to all the targets - but this is difficult to predict when we don't know which targets a particular developer in interested in.
Similar and still stranger considerations apply to dodo.
I'd prefer not to inflict additional build steps upon developers who are not usually tweaking this area
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"make install" performs the copy step (if needed) to copy the .h files from their home in ref-impl to the platform include dir for the user's platform. There is no reason to have .h files under revision control in the platform directory when they are already under revision control in the ref-impl home.
"make install" does the required copy step, and other directories like examples, examples2, test, and Utilties all depend upon the "install" target so the necessary copy step is performed as a prerequisite to building other targets.
During the Havant meetings in January 2004, I asked Jeff Beddel about the history of this situation and he replied that there was once some reason for the MS Windows include files to be modified to avoid some kind of clash of COM definitions. He wasn't sure whether this was still needed for MS Windows, but he did say that it was not needed for all non-MSWindows platforms.
"So I can remove from CVS all those duplicated .h files in the non-MSWindows platform directories?"
"Yes" Jeff replied.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there was another reason, related to updating of time stamps in CVS...I don't remember all the details, but it led us to check in the output of the dodo and meta build steps.
So while I agree with you that if "make install" does the copying, we don't need the checked in intermediate files, I ask:
1. in practice (taking timestamps and checkouts into account) does this result in unnecessary build steps?
2. will this work for app developers who do not want to ever build the complete SDK, and expect just to grab .so and .h?
3. instead of checked in intermediates, do we need a "make dist" build target to create the package on which an app developer can run "make install"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think JF was asking whether the files in ref-impl/include should be duplicated in AAF*SDK/include, not whether the files in ref-impl/include should be generated at build time from AAF/meta.
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still a bit curious: since the include files seem to be straightforward copies of the ones in ref-impl/include, is there really a need for OS-specific include directories? Could there not be a single include directory for all platforms?
JF
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the distinction was made because there are several classes of users of the SDK:
creators - who work on multiple platforms to build a single codebase that can be ported. creators should always work with ref-impl/include
porters - who bug fix the codebase mostly on a single platform. porters are the ones who ensure that "make install" works on behalf of developers. make install will most often directly copy from ref-impl/include to $installdir/include...but on some platforms it MIGHT NOT
developers - who link to the SDK on one or more platforms, and need the same symbolic names. developers should always use $installdir/include, NEVER ref-impl/include
end users - who don't see include files at all
...and, incidentally:
SDK release tarballs only need to contain the files that will be put in $installdir
application release tarballs should only need the files in $installdir/bin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seems to be a mismatch between the following two includes files:
AAFFileKinds.h
AAFMetaDictionary.h
They are different in ref-impl/include and AAFi686LinuxSDK/g++/include
The versions in AAFi686LinuxSDK/g++/include don't seem to have the latest changes. So the question is: should there even be CVS elements in the AAF*SDK directories, or should these only be populated when you build the toolkit for a particular platform?
JF
JF,
I agree with your observation. I have verified that these files do get updated with the versions from ref-impl/include with a make install.
At the very least, I will update the version in AAF*SDK before we do the release. Perhaps they shouldn't be there at all, as you suggest. I have a feeling they are copied to the platform-specific directories due to a detail with MSVC project files. Anyone know the history here?
Phil
The reason they are checked in is to avoid having to do a cd ./meta; make before doing a make all. It could be argued that the makefile in ./meta should incorporate distribution to all the targets - but this is difficult to predict when we don't know which targets a particular developer in interested in.
Similar and still stranger considerations apply to dodo.
I'd prefer not to inflict additional build steps upon developers who are not usually tweaking this area
"make install" performs the copy step (if needed) to copy the .h files from their home in ref-impl to the platform include dir for the user's platform. There is no reason to have .h files under revision control in the platform directory when they are already under revision control in the ref-impl home.
"make install" does the required copy step, and other directories like examples, examples2, test, and Utilties all depend upon the "install" target so the necessary copy step is performed as a prerequisite to building other targets.
During the Havant meetings in January 2004, I asked Jeff Beddel about the history of this situation and he replied that there was once some reason for the MS Windows include files to be modified to avoid some kind of clash of COM definitions. He wasn't sure whether this was still needed for MS Windows, but he did say that it was not needed for all non-MSWindows platforms.
"So I can remove from CVS all those duplicated .h files in the non-MSWindows platform directories?"
"Yes" Jeff replied.
Stuart:
there was another reason, related to updating of time stamps in CVS...I don't remember all the details, but it led us to check in the output of the dodo and meta build steps.
So while I agree with you that if "make install" does the copying, we don't need the checked in intermediate files, I ask:
1. in practice (taking timestamps and checkouts into account) does this result in unnecessary build steps?
2. will this work for app developers who do not want to ever build the complete SDK, and expect just to grab .so and .h?
3. instead of checked in intermediates, do we need a "make dist" build target to create the package on which an app developer can run "make install"?
Silly me, Jim T already did this...
http://sourceforge.net/forum/message.php?msg_id=1615297
I think JF was asking whether the files in ref-impl/include should be duplicated in AAF*SDK/include, not whether the files in ref-impl/include should be generated at build time from AAF/meta.
Phil
He was, and the answer is, they should be duplicated
in AAF*SDK/include, because they cannot be efficiently generated
at build time from AAF/meta
I'm still a bit curious: since the include files seem to be straightforward copies of the ones in ref-impl/include, is there really a need for OS-specific include directories? Could there not be a single include directory for all platforms?
JF
the distinction was made because there are several classes of users of the SDK:
creators - who work on multiple platforms to build a single codebase that can be ported. creators should always work with ref-impl/include
porters - who bug fix the codebase mostly on a single platform. porters are the ones who ensure that "make install" works on behalf of developers. make install will most often directly copy from ref-impl/include to $installdir/include...but on some platforms it MIGHT NOT
developers - who link to the SDK on one or more platforms, and need the same symbolic names. developers should always use $installdir/include, NEVER ref-impl/include
end users - who don't see include files at all
...and, incidentally:
SDK release tarballs only need to contain the files that will be put in $installdir
application release tarballs should only need the files in $installdir/bin