P
Phrogz
Summary: How do I use a single rantfile or rakefile to perform some
varying commands based on data that I want to pass to it?
Background: My company makes a Windows-based middleware product
helping next-gen game developers create UIs. In the process of
creating the UI, our tool gathers information about the raw 3D models
and 2D images and data files and so forth needed to create the end
result. When the artist presses the "Preview" button, the application
needs to essentially perform a 'build' process. Various assets are
conditioned (going from bloated formats to runtime-appropriate
binaries) using various standalone applications. Only those resources
that have changed want to be conditioned, and thus some dependency
management is needed to do as little work as possible as quickly as
possible. Depending on the target platform, some files may need to be
copied over the network to the PS3 or 360 dev kit. The final 'product'
of the build is launching the preview application and passing it some
descriptor to show the end result.
The process changes slightly based on:
* debug/release mode,
* the target platform to preview on,
* the actual project being worked on and the assets it contains
....but otherwise is the same for every project file, for a given
customer. Each customer, however, may change the process entirely.
Question: I'm looking at Rant (or perhaps Rake) for this right now.[1]
The idea is that the application would run a Rant target (perhaps
based on a combination of debug/release and target platform), which
would kick off all the conditioners as appropriate and finally launch
the viewer application.
My question is...how do I pass data to a rantfile? The command line
for rant is just:
rant [-f Rantfile] [Options] [targets]
which gives me no way of simply passing along the name of the project
and other assets from our tool.
Is the best choice to have our tool write out a text file manifest of
all the assets of the various types, and have Rant tasks use that?
[This would sort of match the ability of make (or rant) to derive
dependencies from files with a known format (like C includes).]
Do I build a folder structure and copy/alias all the resources into
known buckets and have Rant enumerate the directories? (I'd have to
copy the rantfile into the right spot to set the context to run with.)
[This would match the *.c->*.o type mentality.]
Do I use something like ERB and have a rantfile template (editable by
customers) that our tool can use to dynamically customize the rantfile
on each preview command?
Is the rant "gen" method (that I don't yet understand) the answer I'm
looking for?
I've only just begun reading the documentation on Rant, and I haven't
used any make system (other than blindly typing "configure/make/make
install") in many, many, many years. Please forgive me (and help) if
I'm asking really basic questions.
Thanks in advance for any help!
[1] I'm also looking at MSBuild, NAnt, and maybe Jam, and maybe
others. I'm leaning towards Rant/Rake right now because I think full
Ruby-based tasks will provide the power and flexibility game customers
will need (no limitations in what can be done) in a clear, clean
fashion.
varying commands based on data that I want to pass to it?
Background: My company makes a Windows-based middleware product
helping next-gen game developers create UIs. In the process of
creating the UI, our tool gathers information about the raw 3D models
and 2D images and data files and so forth needed to create the end
result. When the artist presses the "Preview" button, the application
needs to essentially perform a 'build' process. Various assets are
conditioned (going from bloated formats to runtime-appropriate
binaries) using various standalone applications. Only those resources
that have changed want to be conditioned, and thus some dependency
management is needed to do as little work as possible as quickly as
possible. Depending on the target platform, some files may need to be
copied over the network to the PS3 or 360 dev kit. The final 'product'
of the build is launching the preview application and passing it some
descriptor to show the end result.
The process changes slightly based on:
* debug/release mode,
* the target platform to preview on,
* the actual project being worked on and the assets it contains
....but otherwise is the same for every project file, for a given
customer. Each customer, however, may change the process entirely.
Question: I'm looking at Rant (or perhaps Rake) for this right now.[1]
The idea is that the application would run a Rant target (perhaps
based on a combination of debug/release and target platform), which
would kick off all the conditioners as appropriate and finally launch
the viewer application.
My question is...how do I pass data to a rantfile? The command line
for rant is just:
rant [-f Rantfile] [Options] [targets]
which gives me no way of simply passing along the name of the project
and other assets from our tool.
Is the best choice to have our tool write out a text file manifest of
all the assets of the various types, and have Rant tasks use that?
[This would sort of match the ability of make (or rant) to derive
dependencies from files with a known format (like C includes).]
Do I build a folder structure and copy/alias all the resources into
known buckets and have Rant enumerate the directories? (I'd have to
copy the rantfile into the right spot to set the context to run with.)
[This would match the *.c->*.o type mentality.]
Do I use something like ERB and have a rantfile template (editable by
customers) that our tool can use to dynamically customize the rantfile
on each preview command?
Is the rant "gen" method (that I don't yet understand) the answer I'm
looking for?
I've only just begun reading the documentation on Rant, and I haven't
used any make system (other than blindly typing "configure/make/make
install") in many, many, many years. Please forgive me (and help) if
I'm asking really basic questions.
Thanks in advance for any help!
[1] I'm also looking at MSBuild, NAnt, and maybe Jam, and maybe
others. I'm leaning towards Rant/Rake right now because I think full
Ruby-based tasks will provide the power and flexibility game customers
will need (no limitations in what can be done) in a clear, clean
fashion.