Ferenc Wagner wferi@afavant.elte.hu writes:
It's almost a resend of my previous patch which seems MIA. The only difference is that I removed the possible sequence point screwups in the hope they were the reason for the drop.
New files: programs/winetest/README programs/winetest/resource.h
ChangeLog:
- Build info et al. is given by files instead of env. vars.
- Store that information in resources.
I think it would be much cleaner to have maketest take care of including the files, so that it doesn't require everybody to have dummy files around and avoids that ugliness in the makefile.
Alexandre Julliard julliard@winehq.org writes:
Ferenc Wagner wferi@afavant.elte.hu writes:
It's almost a resend of my previous patch which seems MIA. The only difference is that I removed the possible sequence point screwups in the hope they were the reason for the drop.
New files: programs/winetest/README programs/winetest/resource.h
ChangeLog:
- Build info et al. is given by files instead of env. vars.
- Store that information in resources.
I think it would be much cleaner to have maketest take care of including the files, so that it doesn't require everybody to have dummy files around and avoids that ugliness in the makefile.
My first implementation did exactly that. However, these pieces of information have their places in the depencency tree and I managed to screw up my build more often than not without the help of make. Beyond that, moving this little complexity out of the Makefile leads to much more complexity in a couple of other places. I did my best not to bother uninterested parties by these small files; I think they would go unnoticed. Are you still holding your position?
Btw the real solution to the ugliness would be the use of the .DELETE_ON_ERROR special target, isn't that portable?
Ferenc Wagner wferi@afavant.elte.hu writes:
My first implementation did exactly that. However, these pieces of information have their places in the depencency tree and I managed to screw up my build more often than not without the help of make. Beyond that, moving this little complexity out of the Makefile leads to much more complexity in a couple of other places. I did my best not to bother uninterested parties by these small files; I think they would go unnoticed. Are you still holding your position?
Btw the real solution to the ugliness would be the use of the .DELETE_ON_ERROR special target, isn't that portable?
No, it's not, and frankly I don't see why you would need that. Could you please explain a bit more what you are trying to do?
Alexandre Julliard julliard@winehq.org writes:
Ferenc Wagner wferi@afavant.elte.hu writes:
My first implementation did exactly that. However, these pieces of information have their places in the depencency tree and I managed to screw up my build more often than not without the help of make. Beyond that, moving this little complexity out of the Makefile leads to much more complexity in a couple of other places. I did my best not to bother uninterested parties by these small files; I think they would go unnoticed. Are you still holding your position?
Btw the real solution to the ugliness would be the use of the .DELETE_ON_ERROR special target, isn't that portable?
No, it's not, and frankly I don't see why you would need that. Could you please explain a bit more what you are trying to do?
Oh, that was a real 'btw' side note; I meant the usual ... || ( $(RM) $@ && exit 1 ) stanzas, which we have to keep repeating all to often. I skimmed through the compatibility section in the make manual but found no portability issues with respect to this special target. An overlook, probably.
Back to the topic: my main point is that the situation is best expressed by a Makefile and solved by make. Best as opposed to verbosity and complexity. I suppose this is also a fairly workable scheme for those who build the winetest packages while being transparent for others. And still a very straightforward application of make. I can't really see sane way to do all of this in maketest without triggering superfluous relinks all the time; maybe I miss something obvious.
Ferenc Wagner wferi@afavant.elte.hu writes:
Back to the topic: my main point is that the situation is best expressed by a Makefile and solved by make. Best as opposed to verbosity and complexity. I suppose this is also a fairly workable scheme for those who build the winetest packages while being transparent for others. And still a very straightforward application of make. I can't really see sane way to do all of this in maketest without triggering superfluous relinks all the time; maybe I miss something obvious.
Again, please explain what you are trying to do from a high-level point of view; it may well be that this needs makefile changes, but if so they need to be done cleanly, which isn't the case with your patch I'm afraid.
Alexandre Julliard julliard@winehq.org writes:
Ferenc Wagner wferi@afavant.elte.hu writes:
Back to the topic: my main point is that the situation is best expressed by a Makefile and solved by make. Best as opposed to verbosity and complexity. I suppose this is also a fairly workable scheme for those who build the winetest packages while being transparent for others. And still a very straightforward application of make. I can't really see sane way to do all of this in maketest without triggering superfluous relinks all the time; maybe I miss something obvious.
Again, please explain what you are trying to do from a high-level point of view; it may well be that this needs makefile changes, but if so they need to be done cleanly, which isn't the case with your patch I'm afraid.
Now I got it, hopefully. So: the winetest executable must contain some information about its build process which it can write into the reports. These are: an identification string (usually the checkout date and time but possible something else), a URL where the executable can be downloaded from and a free-format block of other build info like toolchain versions. Some of these are presistent, some more subject to change.
Ferenc Wagner wferi@afavant.elte.hu writes:
Now I got it, hopefully. So: the winetest executable must contain some information about its build process which it can write into the reports. These are: an identification string (usually the checkout date and time but possible something else), a URL where the executable can be downloaded from and a free-format block of other build info like toolchain versions. Some of these are presistent, some more subject to change.
It sounds like what you want is a 'make dist' target that builds a different exe for distribution, one that includes all that info. The standard build shouldn't have to worry about these things.
-
Alexandre Julliard -
Ferenc Wagner