Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=8463


acedit AT armory.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grimoire AT sourcemage.org




------- Additional Comments From acedit AT armory.com  2005-09-24 03:59 -------
how about variables in DETAILS for each major phase whose contents is a 
function
name:
PRE_BUILD_CMD=custom_pre_build
BUILD_CMD=jam_build
INSTALL_CMD=default_install
FINAL_CMD=custom_final

We could expand that beyond the build system to other pipelines like depends
resolution, dispel, etc.

When going to run a spell file, sorcery would then check if the variable is
defined, if it is execute the contents, if not, check for the relavent file -x
and finally calling its own default function. Spell writers could come up with
their own various build systems in grimoire libraries and combine them as they
see fit. As build system functions mature they could be migrated to more
permanent locations.

Other cool things could happen such as the hook doing some pre-actions (adjust
gcc versions, do some workaround, etc) then calling the spell file if its -x 
or
the default_ function. This would give spell writers a lot more power and
control over common tasks without having to add spell files all over the 
place.
For example, adjusting the gcc used in a spell could be done by:

GCC_VERSION=3.4
DEPENDS_CMD="gcc_depends
PRE_BUILD_CMD=gcc_pre_build

Then in FUNCTIONS
gcc_depends() {
case $GCC_VERSION in
3.4) depends gcc34 ;;
3.3) depends gcc33 ;;
*) echo "Unknown gcc version"; return 1 ;;
esac &&
if test -x $SCRIPT_DIRECTORY/DEPENDS; then
source $SCRIPT_DIRECTORY/DEPENDS
fi
}

gcc_pre_build() {
invoke_gcc &&
if test -x $SCRIPT_DIRECTORY/PRE_BUILD; then
source $SCRIPT_DIRECTORY/PRE_BUILD
else
default_pre_build
fi
}

Another example would be to eliminate BUILD when the only thing that needs
setting OPTS.

BUILD_CMD="opts_default_build ${SPELL}_OPTS"

function opts_default_build() {
eval OPTS="$OPTS "$$1""
default_build
}
That would put a (presumably persistent) variable named after the spell into
OPTS, then run the usual build.

--


------- Additional Comments From ruskie AT email.si  2005-09-24 08:51 -------
I'd do CONFIGURE_CMD and MAKE_CMD instead of a BUILD_CMD.
Why? To reduce doubling of the code.

jam based systems still use ./configure with the same options
so basicaly having an autotools_configure, scons_configure,
jam_build, make_build, scons_build Would be nice.

Like the DETAILS idea... I think I was discussing that one on irc
with somebody though and someone mentioned that we don't want more
vars in DETAILS.

I accually like it to be settable in DETAILS. One less file to have
in the spell.

--


------- Additional Comments From acedit AT armory.com  2005-09-24 18:16 -------
(In reply to comment #3)
> I'd do CONFIGURE_CMD and MAKE_CMD instead of a BUILD_CMD.
> Why? To reduce doubling of the code.

You could do this on your end:
BUILD_CMD="autotools_configure && jam_build"

Also, CONFIGURE_CMD would confuse itself with overriding the CONFIGURE file 
that
runs before DEPENDS.

> 
> jam based systems still use ./configure with the same options
> so basicaly having an autotools_configure, scons_configure,
> jam_build, make_build, scons_build Would be nice.
> 
> Like the DETAILS idea... I think I was discussing that one on irc
> with somebody though and someone mentioned that we don't want more
> vars in DETAILS.
> 
> I accually like it to be settable in DETAILS. One less file to have
> in the spell.

Exactly. You're going to have to have the info _somewhere_, so either theres a
file with a single line in it, or a line in DETAILS doing the same thing at 
much
less cost. If someone doesnt want more lines in their spell's DETAILS file 
they
can add a file. Its up to them how they want to do it since the same functions
available to the *_CMD vars are accessible in the spell files.


-- 


------- Additional Comments From acedit AT armory.com  2005-09-24 18:16 -------
(In reply to comment #3)
> I'd do CONFIGURE_CMD and MAKE_CMD instead of a BUILD_CMD.
> Why? To reduce doubling of the code.

You could do this on your end:
BUILD_CMD="autotools_configure && jam_build"

Also, CONFIGURE_CMD would confuse itself with overriding the CONFIGURE file 
that
runs before DEPENDS.

>
> jam based systems still use ./configure with the same options
> so basicaly having an autotools_configure, scons_configure,
> jam_build, make_build, scons_build Would be nice.
>
> Like the DETAILS idea... I think I was discussing that one on irc
> with somebody though and someone mentioned that we don't want more
> vars in DETAILS.
>
> I accually like it to be settable in DETAILS. One less file to have
> in the spell.

Exactly. You're going to have to have the info _somewhere_, so either theres a
file with a single line in it, or a line in DETAILS doing the same thing at 
much
less cost. If someone doesnt want more lines in their spell's DETAILS file 
they
can add a file. Its up to them how they want to do it since the same functions
available to the *_CMD vars are accessible in the spell files.


--


------- Additional Comments From ruskie AT email.si  2005-09-24 18:42 -------
ohhh yeah.... then I guess that's satisfactory for me...
Anyone else have issues with this?

--


------- Additional Comments From acedit AT armory.com  2005-11-10 19:12 -------
adding grimoire to cc list so he knows about the request, if I dont hear
anything back I'll go ahead and implement this as detailed above.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.