Questions re Jamfile for testing
I've been making adjustments to the serialization library to permit it to be used as a DLL and I have a couple of questions. As an example, I looked at the Jamfile for testing the filesystem. It contains: test-suite "filesystem" : [ run libs/filesystem/test/path_test.cpp <lib>../../../libs/filesystem/build/boost_filesystem : : : <define>BOOST_ALL_NO_LIB=1 ] ... a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation of the libraries. Is this correct? b) the requirements included <lib> ... but not <dll>. Does this test Jamfile EVER test the dll version of the filesystem library? Now suppose the test is built with runtime-link/dll . I believe that would indicate that the msvc dll version of the C++ libraries will be used and the compiler will compile code accordingly. On the other hand the <lib> above suggests that this test should be built with static linking. This raises a couple of questions: a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used? By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used. Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries. c) ideally, if we had nothing but time I would like to be able to test all combinations debug/release <runtime-link>static/dynamic, <filesystem library>static/dynamic. What would be the most convenient way to do this. Robert Ramey
Robert Ramey wrote:
a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used? By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used. Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries.
I have argued this case before in general, and agree with it. In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern. When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library. I know that whether the dll or static version of the run-time library is used can be detected at compile time from preprocessor #defines for Microsoft's Visual C++ and Borland's C++ Builder but I do not know if this is the case for other implementations.
Edward Diener wrote:
I have argued this case before in general, and agree with it.
I think I've been in that argument ;-)
In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern.
I haven't. For me the choice of runtime has always been independent of the type of product I'm building.
When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library.
That is not a binary comparison. It's common to distribute executables with dlls and use the dynamic runtime. It's also common to distribute libs that use the dynamic runtime, so that users can build either exes or dlls from that library. It is not as common to distribute a dll that uses the static runtime, but it's not unheard of. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Edward Diener wrote:
I have argued this case before in general, and agree with it.
I think I've been in that argument ;-)
In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern.
I haven't. For me the choice of runtime has always been independent of the type of product I'm building.
When building products for yourself, you can choose your own mix. When distributing 3rd party libraries which use auto-linking, you need to decide how that should work for others. I still think that auto-linking should be dynamic rtl-dll and static rtl-static lib. Of course a more flexible system might allow auto-linking to be turned off and the end-programmer allowed to manually choose.
When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library.
That is not a binary comparison. It's common to distribute executables with dlls and use the dynamic runtime. It's also common to distribute libs that use the dynamic runtime, so that users can build either exes or dlls from that library.
What about the user who wants to use one's 3rd party library and wants to distribute the final executable as a self-contained file not relying on any other dlls ? This can not be done if you only have libraries, whether static or dynamic, which use the run-time dlls. Of course you may argue that a user who wishes to do this is not very common, but my experience is that they are, and are pretty adamant that such a scenario should be supported by 3rd party libraries which they use.
Edward Diener wrote:
Rene Rivera wrote:
Edward Diener wrote:
In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern.
I haven't. For me the choice of runtime has always been independent of the type of product I'm building.
When building products for yourself, you can choose your own mix. When distributing 3rd party libraries which use auto-linking, you need to decide how that should work for others.
I didn't realize auto-linking was part of this argument. So far, as the subject says, we are talking about *testing* not auto-linking.
I still think that auto-linking should be dynamic rtl-dll and static rtl-static lib. Of course a more flexible system might allow auto-linking to be turned off and the end-programmer allowed to manually choose.
You mean like the currently implemented flexible system that allows you to turn off auto-linking and build or use any variant you want?
When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library.
That is not a binary comparison. It's common to distribute executables with dlls and use the dynamic runtime. It's also common to distribute libs that use the dynamic runtime, so that users can build either exes or dlls from that library.
What about the user who wants to use one's 3rd party library and wants to distribute the final executable as a self-contained file not relying on any other dlls ? This can not be done if you only have libraries, whether static or dynamic, which use the run-time dlls. Of course you may argue that a user who wishes to do this is not very common, but my experience is that they are, and are pretty adamant that such a scenario should be supported by 3rd party libraries which they use.
OK, I must be confused... You made the binary choice comparison. I made the counter that it's not possible or desirable to make such binary choices as it's up to he user what they need. And now you are siding with what I said. Which argument are you trying to make? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Edward Diener wrote:
Rene Rivera wrote:
Edward Diener wrote:
In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern.
I haven't. For me the choice of runtime has always been independent of the type of product I'm building.
When building products for yourself, you can choose your own mix. When distributing 3rd party libraries which use auto-linking, you need to decide how that should work for others.
I didn't realize auto-linking was part of this argument. So far, as the subject says, we are talking about *testing* not auto-linking.
I was originally responding to Mr. Ramey's idea that static libs normally use the static RTL and dlls normally use the dynamic RTL. This goes for when libraries are built. I think that other modules that use the library should normally work the same way unless the end-programmer wants to change it manually.
I still think that auto-linking should be dynamic rtl-dll and static rtl-static lib. Of course a more flexible system might allow auto-linking to be turned off and the end-programmer allowed to manually choose.
You mean like the currently implemented flexible system that allows you to turn off auto-linking and build or use any variant you want?
I am glad to hear it. I thought the auto-link defaults were wrong but perhaps I am mistaken. My impression was that the auto-link default for building a static library uses the dynamic version of the RTL.
When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library.
That is not a binary comparison. It's common to distribute executables with dlls and use the dynamic runtime. It's also common to distribute libs that use the dynamic runtime, so that users can build either exes or dlls from that library.
What about the user who wants to use one's 3rd party library and wants to distribute the final executable as a self-contained file not relying on any other dlls ? This can not be done if you only have libraries, whether static or dynamic, which use the run-time dlls. Of course you may argue that a user who wishes to do this is not very common, but my experience is that they are, and are pretty adamant that such a scenario should be supported by 3rd party libraries which they use.
OK, I must be confused... You made the binary choice comparison. I made the counter that it's not possible or desirable to make such binary choices as it's up to he user what they need. And now you are siding with what I said. Which argument are you trying to make?
My argument is that default auto-link configuration, whether building or testing, should be that libs use the static library version of the RTL and any other libraries they use and that dlls use the dynamic library version of the RTL and any other libs they use. Without auto-link programmers building modules are free to do whatever they want.
Robert Ramey wrote:
I've been making adjustments to the serialization library to permit it to be used as a DLL and I have a couple of questions.
As an example, I looked at the Jamfile for testing the filesystem. It contains:
test-suite "filesystem" : [ run libs/filesystem/test/path_test.cpp <lib>../../../libs/filesystem/build/boost_filesystem : : : <define>BOOST_ALL_NO_LIB=1 ] ...
a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation of the libraries. Is this correct?
Yes.
b) the requirements included <lib> ... but not <dll>. Does this test Jamfile EVER test the dll version of the filesystem library?
No it never does, and perhaps it should, but that's up to Beman.
Now suppose the test is built with runtime-link/dll . I believe that would indicate that the msvc dll version of the C++ libraries will be used and the compiler will compile code accordingly. On the other hand the <lib> above suggests that this test should be built with static linking.
Why does it suggest that? It's perfectly acceptable, and common, to use the dynamic runtime in a link library.
This raises a couple of questions:
a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used?
Why?
By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used.
Again, why?
Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries.
Ah, it's a presumption... What you are saying is that we should globally mandate that tests be performed such that DLLs be tested only against the dynamic runtime and and LIBs against the static runtime. What about the users of LIBs that use the dynamic runtime? (I'm one of those)
c) ideally, if we had nothing but time I would like to be able to test all combinations debug/release <runtime-link>static/dynamic, <filesystem library>static/dynamic. What would be the most convenient way to do this.
1. Make sure that there are both <lib> and <dll> tests. (program_options currently does it) 2. Run the test with "-sBUILD=debug release <runtime-link>static/dynamic". Which will build 4 variants. 2b. Or if you are also interested in threading you can run the test with "-sBUILD=debug release <runtime-link>static/dynamic <threading>single/multi". Which will build 8 variants, if supported by the toolset. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (3)
-
Edward Diener -
Rene Rivera -
Robert Ramey