Skip to main content
_
_gverig_
Participant
March 14, 2008
Question

Is there a reason why ant tasks spawn compiler process?

  • March 14, 2008
  • 3 replies
  • 802 views
Subj. Is there a reason why it wouldn't make sense to just pull in Compc or Mxmlc into Ant process (something like calling flex2.tools.Compiler.mxmlc(...) or even hooking deeper into compiler and skipping whole "encode parameters as command line options->parse command line options" step?
This topic has been closed for replies.

3 replies

_
_Jono_Spiro_
Participating Frequently
March 14, 2008
Haha yeah, I get these on my phone while my dog romps around :)

Fork, if I remember correctly:
<mxmlc fork="true" .../>

It is not default to true to save memory and keep everything in the same process as you saw. However, it was added because sometimes the jvm can fill up and run out of memory if you do too many large compiles, rarely needed (and you can always give it more memory...).

Jono



On Mar 13, 2008, at 7:00 PM, gverig < member@adobeforums.com> wrote:

A new message was posted by gverig in



Developers --

  Is there a reason why ant tasks spawn compiler process?



Primarily we would save JVM warm-up which depending on the platform can be pretty significant. This does not affect executing a single task but it adds up as you build multiple modules. There can be other benefits, like tighter integration with ant and path structures, less places to break on decoding/encoding parameters, overall cleanliness of control hand-off.

Said all this, It actually seems that tasks to run in the same VM (there is a 'fork' field, defaults to 'false' and I don't see that it's set anywhere to 'true'. Which would explain why relative paths are no longer resolved based on project basedir (and in Flex2 sdk) but instead are resolved based on the path from which ant process was started... I was actually going to the browser to post a 'recall note' when I saw your reply (thanks btw, I didn't expect a reply this fast!)




View/reply at Is there a reason why ant tasks spawn compiler process?

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.


_
_gverig_Author
Participant
March 14, 2008
Primarily we would save JVM warm-up which depending on the platform can be pretty significant. This does not affect executing a single task but it adds up as you build multiple modules. There can be other benefits, like tighter integration with ant and path structures, less places to break on decoding/encoding parameters, overall cleanliness of control hand-off.

Said all this, It actually seems that tasks to run in the same VM (there is a 'fork' field, defaults to 'false' and I don't see that it's set anywhere to 'true'. Which would explain why relative paths are no longer resolved based on project basedir (and in Flex2 sdk) but instead are resolved based on the path from which ant process was started... I was actually going to the browser to post a 'recall note' when I saw your reply (thanks btw, I didn't expect a reply this fast!)
_
_Jono_Spiro_
Participating Frequently
March 14, 2008
It's a very inexpensive step, and greatly simplifies adding features and supporting ant. Not to mention keeping us honest about how the commandline works functionally against FB and ant tasks. Do you think there's something to be gained?

Jono



On Mar 13, 2008, at 6:11 PM, gverig < member@adobeforums.com> wrote:

A new discussion was started by gverig in



Developers --

  Is there a reason why ant tasks spawn compiler process?



Subj. Is there a reason why it wouldn't make sense to just pull in Compc or Mxmlc into Ant process (something like calling flex2.tools.Compiler.mxmlc(...) or even hooking deeper into compiler and skipping whole "encode parameters as command line options->parse command line options" step?




View/reply at Is there a reason why ant tasks spawn compiler process?

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.


Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices