Err, "Wow, a 4000 line mk file!" On Mon, Jan 17, 2011 at 3:00 PM, Robert Raschke <[email protected]>wrote:
> Terribly sorry, my email won't help you much, apart from going "Wow, a 4000 > link mk file!" and "Hmm, I wouldn't start from here if you want to go > there." Your email also doesn't explain why you cannot generate a "normal" > mk file. > > If you want to stick with your approach, it almost looks like you may be > better off to generate a shell script that explicitly checks and runs > everything you need. (And yes, essentially make your "generator" be a make > in it's own right. Another one won't hurt.) > > But it's cool to see someone else who uses Erlang and RabbitMQ hanging out > on this list. :-) > > Robby > > > On Mon, Jan 17, 2011 at 2:47 PM, Ciprian Dorin Craciun < > [email protected]> wrote: > >> Hello all! >> >> Sorry for interrupting again, but I've stumbled on an `mk` issue... >> >> I've written a little Scheme application that generates `mk` >> scripts for building Erlang applications. (See below an extract of one >> of my previous emails describing just the generator part; the thread >> had the subject: <<mk (from plan9ports) modification time resolution >> issue?>>.) >> >> Now the problem is that the generated script (attached to this >> email) has about 2671 prerequisites (` target :: prerequisite `), and >> about 684 actual targets with recipes. (As I've explained below I'm >> not using any meta-rules, and I'm explicit about each resulting file >> and it's dependencies.) >> >> The problem is that the time needed to run the script has >> extremely increased, and the processor is 100% eaten by `mk`. >> >> For example: >> * just running the `mk` script with the `-n` option takes about 14 >> seconds. >> * using the commands from the `mk -n` takes about 1 minute and 36 >> seconds; >> * then running `mk` takes another 14 seconds; (as it has nothing); >> * but after cleaning and running `mk` (which I've left running for >> about 5 minutes and still didn't finished) it seems that between each >> target (or batch of targets?) it stays about 14 seconds; >> >> But what is strange is that if instead to build the default target >> that builds everything I start building little by little independent >> parts, it works without that great delay... >> >> Any ideas what could cause this? >> >> Thanks, >> Ciprian. >> >> >> ---------- >> [[ Extract from the previous email. ]] >> ---------- >> >> BTW... People might wonder how come I have 367 targets (with 1221 >> prerequisites) for such a small project? :) The answers is I don't >> write the `mk` script by hand, but I've written a small Scheme >> application that just generates the `mk` script based on descriptions >> like the following. (Thus the resulting `mk` script is quite >> exhaustive with quite tight dependencies and doesn't use >> meta-rules...) :) >> >> So just out of curiosity are there any `mk` script generators out there? >> >> Ciprian. >> >> >> ~~~~ >> (vbs:require-erlang) >> >> (vbs:define-erlang-application 'rabbit >> erl: "\\./(rabbitmq-server--latest/src|generated)/.*\\.erl" >> hrl: "\\./(rabbitmq-server--latest/include|generated)/.*\\.hrl" >> additional-ebin: "\\./generated/rabbit\\.app") >> >> (vbs:define-erlang-application 'rabbit_common >> erl: >> "\\./(rabbitmq-server--latest/src|generated)/(rabbit_writer|rabbit_reader|rabbit_framing_amqp_0_8|rabbit_framing_amqp_0_9_1|rabbit_framing_channel|rabbit_basic|rabbit_binary_generator|rabbit_binary_parser|rabbit_channel|rabbit_exchange_type|rabbit_misc|rabbit_net|rabbit_heartbeat|rabbit_msg_store_index|gen_server2|priority_queue|supervisor2)\\.erl" >> hrl: "\\./(rabbitmq-server--latest/include|generated)/.*\\.hrl" >> additional-ebin: "\\./generated/rabbit_common\\.app") >> >> (vbs:define-erlang-application 'amqp_client >> dependencies: 'rabbit_common >> erl: "\\./rabbitmq-erlang-client--latest/src/.*\\.erl" >> hrl: "\\./rabbitmq-erlang-client--latest/include/.*\\.hrl" >> additional-ebin: "\\./generated/amqp_client\\.app") >> ~~~~ >> > >
