Here is what I use to compile Bordeaux-Threads with XCVB.
Is it possible to apply it upstream?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is not recognized in the full amplitude of the word that all freedom is essentially self-liberation -- that I can have only so much freedom as I procure for myself by my ownness. -- Max Stirner
On Fri, Oct 9, 2009 at 8:10 PM, Faré fahree@gmail.com wrote:
Here is what I use to compile Bordeaux-Threads with XCVB.
Is it possible to apply it upstream?
I'd be more inclined to apply this if the changes could be contained within a single file. Plus, since XCVB isn't AFAICT ready for general consumption and none of the developers use it, it would very likely go stale soon.
2009/10/19 Luís Oliveira luismbo@gmail.com:
On Fri, Oct 9, 2009 at 8:10 PM, Faré fahree@gmail.com wrote:
Here is what I use to compile Bordeaux-Threads with XCVB.
Is it possible to apply it upstream?
I'd be more inclined to apply this if the changes could be contained within a single file. Plus, since XCVB isn't AFAICT ready for general consumption and none of the developers use it, it would very likely go stale soon.
The changes could conceivably be contained in a single file, though unhappily not with the current version of XCVB. Also, it makes things noticeably harder for the Make backend if the meaning of a file depends on data in a central file shared by all - basically, you can't let Make rely on timestamps anymore, and/or you must rebuild everything when the central file changes. Which is one of the annoyances of ASDF.
Moreover, note that going stale in wholly independent of whether or not it is in a single file. The data to maintain isn't bigger or smaller in either cases - it's just in a different place.
Also, because unlike simpler systems, the CFFI system definition does a lot of conditional compilation, it is not the kind of things that is fully automated by the conversion process. And so, it is much easier to merge information if the patch is applied and a few things may possibly have to be updated, than if it isn't, and the next user will have to redo the work from scratch or apply a stale patch.
I think the question of which EVAL-WHENs are or aren't necessary is more damning. I admit I didn't try to understand what should be eval-when'ed where and took a shotgun approach to getting my system to work.
If you are still unwilling to commit, I understand. I will "just" have to go through the pains of maintaining my mirror.
An updated patch is attached.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Those who place above society the power of politics and bureaucracies as solutions to all human problems ignore that when they are not all too humans, politicians and bureaucrats are oh so inhuman.
Faré fahree@gmail.com writes:
The changes could conceivably be contained in a single file, though unhappily not with the current version of XCVB. Also, it makes things noticeably harder for the Make backend if the meaning of a file depends on data in a central file shared by all - basically, you can't let Make rely on timestamps anymore, and/or you must rebuild everything when the central file changes. Which is one of the annoyances of ASDF.
Well, the problem that I personally see is that you urge maintainers to maintain inter-file dependencies in two different places for each file involved.
I thought that you provided an asdf-compatibility mode where you parse the .asd file to obtain the dependency information from. Is that not the case?
-T.
On Fri, Oct 23, 2009 at 3:31 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
I thought that you provided an asdf-compatibility mode where you parse the .asd file to obtain the dependency information from. Is that not the case?
Indeed, it'd be much nicer if XCVB could load ASDF systems verbatim.
-
Faré -
Luís Oliveira -
Tobias C. Rittweiler