[serialization] Fix Jamfile
Robert, in revision 43697 you have added usage requirements to serialization's Jamfile, as follows: http://tinyurl.com/2hbzyu It appears that this change is not necessary. If any other target depends on serialization, then it will implicitly depend on serialization's dependencies. Adding <dependency> to usage requirements will mean that if I have a library depending on serialization, than that library will also have dependency on ../../config/test//BOOST_NO_STD_LOCALE If my library does not use that, there's no reason why it should have a dependency. Furthermore, due to the way Boost is build, this dependency can be added to basically all libraries, which is hardly needed. Because of that, I have removed usage-requirements setting on trunk. Also, I've noticed that you have about 10 commits, all having the same commit message: Support serialization in DLLS Make thread-safe fix portable binary archives It does not seem a good practice, as it's hard to understand what each given commit was meant to do. Can you try to use descriptive messages for each commit. FWIW, good guidelines on writing commit messages can be found at: http://subversion.tigris.org/hacking.html#log-messages Thanks, Volodya
Vladimir Prus wrote:
Robert,
in revision 43697 you have added usage requirements to serialization's Jamfile, as follows:
It appears that this change is not necessary. If any other target depends on serialization, then it will implicitly depend on serialization's dependencies.
Adding <dependency> to usage requirements will mean that if I have a library depending on serialization, than that library will also have dependency on
../../config/test//BOOST_NO_STD_LOCALE
If my library does not use that, there's no reason why it should have a dependency.
Boost serialization currently depends upon correct functioning of std::locale. If your library depends upon boost serialization it necessarily depends upon correct functioning of std::locale. There's no getting around that. If you commment out this dependency and run tests on your library, you will find all the tests related to boost serialization will fail due to either a failure to build the library or a failure of tests to compile or problems detected at run time. In any event, you will have expended a great amount of testing resources building and testing code which is apriori known to fail and generate a table which will show errors in your tests related to serialization. A cursory examination might lead one to conclude that this table shows errors either in your library or in the serialization library. Of course these conclusions are incorrect. So - if a library depends upon serialization - (perhaps MPI) it will not build/tests if serialization cannnot be built/tested - this is as it should be. If a library has some aspects which depend on serialization, then those components/tests (and only those) should be made dependent on the serialization library. (mulit-index perhaps). If and only if the testing system has a functioning serialization library, The related tests will be run. Components and tests which do not depend upon the serialization library will still be run. The test results table will contain pass/fail/ blank - blank meaning "not applicable" This is as it should be.
Furthermore, due to the way Boost is build, this dependency can be added to basically all libraries, which is hardly needed.
I don't know what that means.
Because of that, I have removed usage-requirements setting on trunk.
Which, given my observations above, looks to be mistake to me.
Also, I've noticed that you have about 10 commits, all having the same commit message:
Support serialization in DLLS Make thread-safe fix portable binary archives
It does not seem a good practice, as it's hard to understand what each given commit was meant to do. Can you try to use descriptive messages for each commit. FWIW, good guidelines on writing commit messages can be found at:
This commit involved changes in quite a few files. The comment describes the motivation for the changes. If I do a large SVN check-in to the boost SVN from my system (a windows/XP system) it never completes without some sort of cryptic message/complaint. This has to be fixed using various means such as doing clean up and trying again, or by creating a now directory, updating, merging and trying again, etc. Sometimes the checkin reports error but in fact does show up in th SVN browser, etc. On occasion, the check-in is reported as successful on my system but in fact didn't show up on the server (e.g. ../util/test.jam). So, what should be an atomic check-in of a group of files cannot be done. I assigned the same comment to all the check-ins in order to highight the fact that they are all related. I did have a look at the link above which I hadn't seen before. I think the comment fairly captures the motiviation for the changes.
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Vladimir Prus wrote:
Robert,
in revision 43697 you have added usage requirements to serialization's Jamfile, as follows:
It appears that this change is not necessary. If any other target depends on serialization, then it will implicitly depend on serialization's dependencies.
Adding <dependency> to usage requirements will mean that if I have a library depending on serialization, than that library will also have dependency on
../../config/test//BOOST_NO_STD_LOCALE
If my library does not use that, there's no reason why it should have a dependency.
Boost serialization currently depends upon correct functioning of std::locale. If your library depends upon boost serialization it necessarily depends upon correct functioning of std::locale. There's no getting around that.
If you commment out this dependency and run tests on your library, you will find all the tests related to boost serialization will fail due to either a failure to build the library or a failure of tests to compile or problems detected at run time. In any event, you will have expended a great amount of testing resources building and testing code which is apriori known to fail and generate a table which will show errors in your tests related to serialization. A cursory examination might lead one to conclude that this table shows errors either in your library or in the serialization library. Of course these conclusions are incorrect.
So - if a library depends upon serialization - (perhaps MPI) it will not build/tests if serialization cannnot be built/tested - this is as it should be.
Say library A depends on serialization. Serialization itself depends on config/whatever. Then, if config/whatever fails, the serialization build will fail. Then, in turn, will cause library A build to fail. So, no test for library A will run, either.
Because of that, I have removed usage-requirements setting on trunk.
Which, given my observations above, looks to be mistake to me.
Can you, in light of above, clarify exactly will target will be build when it should not be built?
Also, I've noticed that you have about 10 commits, all having the same commit message:
Support serialization in DLLS Make thread-safe fix portable binary archives
It does not seem a good practice, as it's hard to understand what each given commit was meant to do. Can you try to use descriptive messages for each commit. FWIW, good guidelines on writing commit messages can be found at:
This commit involved changes in quite a few files. The comment describes the motivation for the changes. If I do a large SVN check-in to the boost SVN from my system (a windows/XP system) it never completes without some sort of cryptic message/complaint. This has to be fixed using various means such as doing clean up and trying again, or by creating a now directory, updating, merging and trying again, etc.
Hmm, a commit that fails because a post-commit hook rejects commit should not require any of this. I also find it hard to imagine any local misconfiguration that might cause this. What are the exact error message you get from SVN?
Sometimes the checkin reports error but in fact does show up in th SVN browser, etc. On occasion, the check-in is reported as successful on my system but in fact didn't show up on the server (e.g. ../util/test.jam).
This is just impossible. When SVN client reports "Comitted revision XXX", it means the transaction is done on the server. It cannot disappear without some admin work (if if that admin work is done, your local copy will broken beyond repair). Or do you mean Trac SVN browser? That might in theory introduce some delay, but I never noticed it.
So, what should be an atomic check-in of a group of files cannot be done. I assigned the same comment to all the check-ins in order to highight the fact that they are all related. I did have a look at the link above which I hadn't seen before. I think the comment fairly captures the motiviation for the changes.
Except that the comment gave me no clue whatsoever why Jamfile.v2 was changed the way it was. And it was not like I was browing history for no purpose, instead, I was researching a build failure reported by a user: http://svn.boost.org/trac/boost/ticket/1698 - Volodya
Say library A depends on serialization. Serialization itself depends on config/whatever. Then, if config/whatever fails, the serialization build will fail. Then, in turn, will cause library A build to fail. So, no test for library A will run, either.
Correct - that is as it should be. If A depends on serializaiton and serialization depends upon config/whatever, and config/whatever fails, then there is no point in running/testing serialization nor anything that depends upon it. That's what "dependency" means.
Can you, in light of above, clarify exactly will target will be build when it should not be built?
To repeat. in this example, building A would be a mistake as it depends on something that is known not to work. Building A under these circumstances is at best a waste of resources and at worst very missleading.
Hmm, a commit that fails because a post-commit hook rejects commit should not require any of this. I also find it hard to imagine any local misconfiguration that might cause this. What are the exact error message you get from SVN?
I reported one of them on this list when it occurred. There was no response. It was complaining about a mime-type. I tried everything to address it. Finally I created a new directory and made a new update then retried the operation (adding a new file) and it worked fine.
Sometimes the checkin reports error but in fact does show up in th SVN browser, etc. On occasion, the check-in is reported as successful on my system but in fact didn't show up on the server (e.g. ../util/test.jam).
This is just impossible. When SVN client reports "Comitted revision XXX", it means the transaction is done on the server. It cannot disappear without some admin work (if if that admin work is done, your local copy will broken beyond repair). Or do you mean Trac SVN browser? That might in theory introduce some delay, but I never noticed it.
LOL. I'm just reporting what I observed. Of course, you're free to conclude that my observations might have been mistaken, but I assure you, I'm not making this up. The offending file WAS missing and it was shown on my local machine with a green checkmark indicating that it was in sync with the server. - which is why I assumed that it was checked in which was why the whole problem occurred. Note that I have an SVN server on my local machine which I use for my other work on a regular basis (without any problems). Though I'm not an expert, I'm not a complete noob when it comes to SVN usage. Robert Ramey
Robert Ramey wrote:
Say library A depends on serialization. Serialization itself depends on config/whatever. Then, if config/whatever fails, the serialization build will fail. Then, in turn, will cause library A build to fail. So, no test for library A will run, either.
Correct - that is as it should be. If A depends on serializaiton and serialization depends upon config/whatever, and config/whatever fails, then there is no point in running/testing serialization nor anything that depends upon it. That's what "dependency" means.
Can you, in light of above, clarify exactly will target will be build when it should not be built?
To repeat. in this example, building A would be a mistake as it depends on something that is known not to work. Building A under these circumstances is at best a waste of resources and at worst very missleading.
Your Jamfile had two things: requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE usage-requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE The first if just enough, as far as I can see. Why did you add the second? Do I miss any case where the first one is not sufficient?
Hmm, a commit that fails because a post-commit hook rejects commit should not require any of this. I also find it hard to imagine any local misconfiguration that might cause this. What are the exact error message you get from SVN?
I reported one of them on this list when it occurred. There was no response. It was complaining about a mime-type.
There was a response; Stefan has wrote: There is neither a 'mimi-type', nor a 'mim-type', but a 'mime-type'. May be it works with that spelling ?
I tried everything to address it. Finally I created a new directory and made a new update then retried the operation (adding a new file) and it worked fine.
Sometimes the checkin reports error but in fact does show up in th SVN browser, etc. On occasion, the check-in is reported as successful on my system but in fact didn't show up on the server (e.g. ../util/test.jam).
This is just impossible. When SVN client reports "Comitted revision XXX", it means the transaction is done on the server. It cannot disappear without some admin work (if if that admin work is done, your local copy will broken beyond repair). Or do you mean Trac SVN browser? That might in theory introduce some delay, but I never noticed it.
LOL. I'm just reporting what I observed. Of course, you're free to conclude that my observations might have been mistaken, but I assure you, I'm not making this up. The offending file WAS missing
Was missing where? In a fresh svn checkout, or in Trac, or in output of "svn ls <reporsitory url>"?
and it was shown on my local machine with a green checkmark indicating that it was in sync with the server. - which is why I assumed that it was checked in which was why the whole problem occurred.
Oh, you're using some GUI. It might be acting up, then. - Volodya
Vladimir Prus wrote:
Robert Ramey wrote: Your Jamfile had two things:
requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE usage-requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE
The first if just enough, as far as I can see. Why did you add the second? Do I miss any case where the first one is not sufficient?
Well, I concede that bjam file syntax is inpenetrable to me. I don't remember how I ended up with both of these. I suppose that I had concluded that "requirements" was to list a requirement to build the library while "usage-requirements" was to list a requirement to use the library. This could occur because the standard library is required to work for the library to build. Also, since std io headers are used when templates are instantiated, I added the dependency the "usage requiremement" But of course now I don't remember what I was thinking - if anything. Note that including this did produce the effect that I desired. For example, when building the library for mingw which doesn't support wide char i/o the library build and tests for wide char io are automatically skipped as was my intention. Presumably they will be skipped on any platform which doesn't support wide char i/o without anyone having to make any special provision such as markup etc. So, now that I've described my intention as far as "dependency" is concerned, perhaps you might suggest how it might be better expressed. While you're at it, you might explain something else. I included "test.jam" so that my other test directories (performance tests, no-rtti, not checked in) could share the bjam code. I was supprised to find that this file had to be named "test.jam" rather than "test.v2" as I would have expected.
and it was shown on my local machine with a green checkmark indicating that it was in sync with the server. - which is why I assumed that it was checked in which was why the whole problem occurred.
Oh, you're using some GUI. It might be acting up, then.
I use tortoise SVN for window/XP. Which is very cool interface. But like all such things - sometimes its a little "truculant". Oh well - maybe there is a god. Robert Ramey
Robert Ramey wrote:
Vladimir Prus wrote:
Robert Ramey wrote: Your Jamfile had two things:
requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE usage-requirements <dependency>../../config/test//BOOST_NO_STD_LOCALE
The first if just enough, as far as I can see. Why did you add the second? Do I miss any case where the first one is not sufficient?
Well, I concede that bjam file syntax is inpenetrable to me. I don't remember how I ended up with both of these. I suppose that I had concluded that "requirements" was to list a requirement to build the library while "usage-requirements" was to list a requirement to use the library. This could occur because the standard library is required to work for the library to build. Also, since std io headers are used when templates are instantiated, I added the dependency the "usage requiremement" But of course now I don't remember what I was thinking - if anything.
Note that including this did produce the effect that I desired. For example, when building the library for mingw which doesn't support wide char i/o the library build and tests for wide char io are automatically skipped as was my intention. Presumably they will be skipped on any platform which doesn't support wide char i/o without anyone having to make any special provision such as markup etc.
So, now that I've described my intention as far as "dependency" is concerned, perhaps you might suggest how it might be better expressed.
I think that leaving just the 'requirements' block above should have the desired effect -- and that's why I did.
While you're at it, you might explain something else. I included "test.jam" so that my other test directories (performance tests, no-rtti, not checked in) could share the bjam code. I was supprised to find that this file had to be named "test.jam" rather than "test.v2" as I would have expected.
The modules that you import should have .jam extention, whereas Jamfiles have more flexible rules, and for C++ Boost, Jamfile.v2 is allowed, which was used to avoid conflicts with Boost.Build V1. The ".v2" extension is not special in any way -- it's C++ Boost setup that tells that Jamfile.v2 is OK. - Volodya
participants (2)
-
Robert Ramey -
Vladimir Prus