not a necessity but would be nice to be able to integrate into a single
file that could be modified once rather than the three separately
maintained build scripts.

edit]
make scripts from john houck

message from john:

here is the ant build script along with some information about ant.

> ant home page:

http://ant.apache.org/

> to see what tasks are built into ant check out:

http://ant.apache.org/manual/index.html

to get a feel for what ant can do, click on 'Ant Tasks' to see all the
commands ant wraps.

> good tutorial on how to use ant:

http://www.onjava.com/lpt/a/622


so why use ant?
> no more operating specific build scripts.
> checks dependencies so builds are faster.
> integrates well with eclipse and emacs ides so users can write code and
build code all in one environment.


what i have provided here isn't completely implemented. the dist target only
builds a proper binary for mac os x. however, you can still get a feel for ant
and build and run the processing code on any os that has ant installed. in
processing parlance all the functionality provided by "make.sh" for each os is
working, but only the mac os version of "dist.sh" is currently implemented in
the ant build.xml. see the attached "build.README" for usage instructions.


future plans:
> implement dist.sh functionality for all os'.
> test on all platforms.
> create web based documentation for building processing src w/ ant.
> create web based documentation for using ant from within emacs and
eclipse.
> move away from os specific build dirs and build shell scripts.

with the recent changes (in the 014X series) to remove native code and
weird build procedures, now is the time to get rid of all the old
make/dist/run scripts and it actually makes sense to move them to ant.

sooo, if anyone is interested in doing this, please have at it. and ask if
you have questions before starting.

so i decided that i had so many dam* build and distribution issues with
java myself that i'm willing to invest some time here.

my only question at this point would be... i prefer tiny build files for
each component (serial, core, app, ...), and one build file for each
platform over the current approach. does that make sense?

(In reply to comment #3)
> so i decided that i had so many dam* build and distribution issues with
> java myself that i'm willing to invest some time here.
>
> my only question at this point would be... i prefer tiny build files for
> each component (serial, core, app, ...), and one build file for each
> platform over the current approach. does that make sense?

I'm hesitant to raise this now with the recent Ant activity, but I only recently
discovered Proce55ing and want to pipe up with an alternative before too much effort
goes into a revamped build system. Namely, have you considered using Maven for
your build? I spent a few hours last night and tonight and believe I've got core, dxf,
net, pdf, video, serial, opengl building (i.e. all but app, for which I have a few
questions).

Maven is an easy fit with the current code structure and has many benefits. Rather
than taking over this conversation, however, I'll start another thread to make a pitch.

-jeff

edit]
Patch to build Processing with Maven

Attached please find a set of Maven poms to build Processing. These poms only
build the artifacts, they don't assemble a distribution (that'll come later).
Also, due to a conflict of the class files, the class
processing.app.tools.format.src.AutoFormat has been deleted.

After installing Maven and applying the patch, the command 'mvn clean install'
from the root project will build the artifacts for app, core, dxf, net, opengl,
pdf, serial, and video. These can be found in the respective target folders for
each of these sub-projects.

Just for jollies, and to help show the power of Maven type 'mvn site' at the
root to generate a web site and various reports for each of the sub-projects.
Again, these can be found within the target directory for each under the site
directory.

Please let me know if you have any questions...

-jeff

edit]
2nd Maven Build patch

I've improved the Maven build files (poms) from my previous patch. This patch
removes the absolute path to tools.jar and fixes the configuration for the app
project to allow the generated source to be resolved in Eclipse.

As mentioned previously, these build files remove the colliding AutoFormat
class and are limited to building the jars, not creating distributions. Also,
preproc.pl is not used nor replaced. I'll need some help understanding what it
does in order to replace it. Clarification on the AutoFormat situation is also
of interest.

Only one file in Processing is modified with this patch (the 2nd AutoFormat is
deleted). As such it should be very easy to try Maven out. I believe these poms
constitute a significant step in modernizing Processing's build, as well as
making it far more maintainable. I'd like to help move things forward, but I
need some more feedback and especially some insight into aspects of the current
build and code structure. Anybody able to help?

please open a new bug/feature request for the maven work--this bug
specifically relates to the move to ant.

Maven build feature request at:
http://dev.processing.org/bugs/show_bug.cgi?id=1154

For those asking about the move to ant (vs maven, or even another build
platform). The repository will be moving to ant, at least for the time
being. It's a more conservative move but I think we'll have better luck
with finding people who can hack on and maintain ant scripts than maven,
and better general integration/help/howto available for its use with other
projects. If ant it is insufficient, we can move on again to maven.

However, there is no timetable for the move, as this bug has existed since
2005, and nobody has finished building a script that does everything
make.sh and dist.sh do for all three platforms plus command line. It *all*
needs to work, not just 80% or kinda sorta works across platforms, it needs
to be a drop-in replacement that handles everything covered in the current
build setup.

(In reply to comment #9)
>
> For those asking about the move to ant (vs maven, or even another build
> platform). The repository will be moving to ant, at least for the time
> being. It's a more conservative move but I think we'll have better luck
> with finding people who can hack on and maintain ant scripts than maven,
> and better general integration/help/howto available for its use with other
> projects. If ant it is insufficient, we can move on again to maven.

There are two Maven books available online for free:

http://www.scribd.com/doc/210552/better-builds-with-maven
http://www.sonatype.com/books/maven-book/index.html

I'm quite handy with Ant, but I know I'm not the only dev who has lost
interest in it. Over time you may gain as many Ant devs as you lose to
Maven. But I won't press--you get to make your own decision.

My interest in bringing Maven to Processing was two-fold:
1) I wanted to embed Processing in my Maven project
2) I wanted to have source code available for my Processing artifacts (the
expert download doesn't include source)

Once I checked out the code and saw that it was structured much like a
Maven project I thought it was well worth a try to do the conversion. On
the whole I've achieved what I set out to accomplish. I've discovered, too,
that providing Processing jars in a Maven repository would open up a whole
new community to adoption as no installation is required and it's easy to
embed.

> However, there is no timetable for the move, as this bug has existed since
> 2005, and nobody has finished building a script that does everything
> make.sh and dist.sh do for all three platforms plus command line. It *all*
> needs to work, not just 80% or kinda sorta works across platforms, it needs
> to be a drop-in replacement that handles everything covered in the current
> build setup.

I was intending to try to follow through to the end if you selected the
Maven option--and I'm happy to teach you what I know along the way. But I
had questions about the code that needed answers before I could move
forward. In case it ever comes in handy, here are some Maven plugins to
assist in packaging:

http://alakai.org/reference/plugins/launch4j-plugin-usage.html
http://mojo.codehaus.org/osxappbundle-maven-plugin/index.html

Even if you don't choose to use Maven, I'd encourage you to try out what I
posted. In particular, if you run 'mvn site:stage' and look in the
target/staging directory you can see a number of code metrics generated for
the source code. Code duplication and other static code analysis reveals
opportunities for improving the code quality, some of them relatively
inexpensive.

fry - a hypothetical question - would you be okay with changing the folder
structure for a *new* build system?
i'm thinking the following:

* create a dependencies folder that contains all the binaries that are
created by other people and are not handled by the current build process
(antlr, quaqua, jogl, minim, javascript lib, application stubs, rxtx,
reference, etc.)

* the build process would go in three stages:
1. build core and pde to build/core (resp. build/pde)
2. build libraries to build/libraries/
3. build executables (build/windows, build/macosx, build/linux)

and one other build question - what exactly does preproc.pl do and is it
still being used?

What would be gained by moving those files elsewhere? The point of having
them in the repository in the first place is because we have to rely on
particular versions of those items, and often have to fix bugs, alter their
source, or otherwise introduce workarounds for problems.

preproc.pl auto-generates the bottom half of PApplet.java from PGraphics.java.

Re: maven, i'll certainly give it a look, we can discuss maven over in the
other bug report, thanks.

(In reply to comment #12)
>
>
>
> Additional Comment #12 From
> fry
> 2009-02-19 17:26
>
> <!--
> addReplyLink(12); //-->[reply]
>
> preproc.pl auto-generates the bottom half of PApplet.java from
PGraphics.java.

Could you explain the motivation?

> Re: maven, i'll certainly give it a look, we can discuss maven over in the
> other bug report, thanks.

Sounds good.

> Could you explain the motivation?
my three main points:
1. clean structure means clean build system
2. less of a learning curve for people new to the repository
3. the way my suggestion goes i think we can save linux package people lots
of time

edit]
Preprocessor - Ant implementation

I've taken re-written preproc.pl in java and made it an ant task.

in the build scripts later this can be used as follows:
<taskdef
name="preproc"
classname="org.superduper.preproc.PreprocAnt"
classpath="preproc.jar" />
<preproc dir="core/src/processing/core"/>


to try this out extract the archive, then on the command line:
$ cd preproc
$ ant demo
(should output "PApplet updated")
$ ant demo
(should output "No updates to PApplet")

have fun, hope that helps...
btw. to compile this you must adapt the path to "ant.jar" in build.xml, running
the demo should just work out of the box.

(In reply to comment #14)
> > Could you explain the motivation?
> my three main points:

No, sorry, Hansi,

I was asking Ben what the motivation was for doing the preproc step at all.
What problem is it intended to solve?

-jeff

At its simplest, not having to write "g." in front of all functions that
relate to the graphics API.

> No, sorry, Hansi,
oops, i intended to quote the entry from two comments above ("What would be
gained by moving those files elsewhere?" )

@fry
more questions regarding the build process:

1. in Base.java: what is the difference between REVISION_NUMBER and
VERSION_NAME?
2. in what way is launch4j modified? is this about adding tools.jar to the
classpath?

sorry for keeping you busy on what seem "non-issues", will post something
to play around with tomorrow, promise :)

One is a printable string for the UI and also used by the build system, the
other is used in code for version checking.

launch4j has a handful of edits to deal with bugs and will have more as I
continue to debug the launcher on other platforms.

But to be clear, I am *not* redoing the entire folder hierarchy and the way
that the build is put together. This bug is to redo the current system with
ant. As noted in the howto, the build is constructed the way it is so that
I can efficiently put together releases.

And let's also be clear that building on Linux (assuming you have developer
tools installed) couldn't be easier. It's three steps:

1. svn co ...
2. cd build/linux
3. ./make.sh

It's completely self-contained, and is built to work that way. For a tiny
percentage of people who are using 64-bit operating systems, it requires
you to replace the 'java' folder with a symlink.

These issues about things being too "difficult" or subjective disagreements
with the folder hierarchy are getting silly.

Ben, are you open to constructive criticism, both personally and with
respect to the code?

(In reply to comment #20)
>
>
>
> Additional Comment #20 From
>
> fry
> 2009-02-24 17:36
>
> <!--
> addReplyLink(20); //-->[reply]
>
>
>
>
> launch4j has a handful of edits to deal with bugs and will have more as I
> continue to debug the launcher on other platforms.
hm... not exactly sure, but i'll just try finding those bugs in the tracker...
>
> But to be clear, I am *not* redoing the entire folder hierarchy and the way
> that the build is put together. This bug is to redo the current system with
> ant. As noted in the howto, the build is constructed the way it is so that
> I can efficiently put together releases.
my question was NEVER to "redo the ENTIRE folder structure", my question
was about moving stuff a little bit around to make things cleaner and
clearer... you know... just a little spring cleaning.

>
> And let's also be clear that building on Linux (assuming you have developer
> tools installed) couldn't be easier. It's three steps:
>
> 1. svn co ...
> 2. cd build/linux
> 3. ./make.sh
>
> It's completely self-contained, and is built to work that way. For a tiny
> percentage of people who are using 64-bit operating systems, it requires
> you to replace the 'java' folder with a symlink.
>
> These issues about things being too "difficult" or subjective disagreements
> with the folder hierarchy are getting silly.
Yea, there's been ONE question about the folder structure which I started
with "a hypothetical question" and received ONE response by you which was
very vague.

If you didn't notice - the two questions above come directly from trying to
understand the current build process.

(In reply to comment #21)
>
> Ben, are you open to constructive criticism, both personally and with
> respect to the code?

I'll take your silence as a no. In that case I will only observe that both
by your action and inaction you have been dismissive of members of this
community. This is very discouraging and calls into question whether
contributions and discourse are welcomed here.

There is a chance to see this patch to come more than a patch?

Now in use as the default build system. Old system is in the process of
being removed as bugs are worked out and I get a chance to update the
documentation.

Thanks 1000x to Hansi!