#
# Makefile for building Calendar Tool jar files, including notes on executing
# compiled Java programs.  Also some notes at the bottom regarding debugging
# compiled Java programs in Emacs.
#

# Java 6 tools.
JAR = /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Commands/jar

# CSC 206 java lib directory
LIB206 =	/users/gfisher/classes/206/lib/JVM


#
# NOTES ABOUT EXECUTING COMPILED JAVA PROGRAMS.
#

# The compilation rule in the implementation/source/java/Makefile results in an
# executable program that consists of .class files stored in this directory --
# implementation/executables/JVM.  The program can be invoked as follows from
# this directory:
#
#     java caltool.Main
#
# where "caltool" is the name of the top-level project package, and Main is the
# name of the class that contains the definition of the program's main method.
# Executing in this way assumes that the CLASSPATH environment variable
# includes the path of the CSC 206 library directory, which on waldorf is
#
#     /users/faculty/gfisher/classes/206/lib/JVM
#
# If CLASSPATH does not include this path, then the program can be invoked by
# specifying the CLASSPATH as a command-line argument as follows:
#
#     java -classpath /users/gfisher/classes/206/lib/JVM:. \
	  caltool.Main
#
# Per standard Java invocation conventions, the preceding invocations assume
# that the current working directory is the executables/JVM directory in which
# the .class files reside.  If this is not the case, then the classpath must be
# extended with the directory in which the compiled package resides.
# Specifically, to run caltool.Main from some directory other than JVM,
# invoke it as follows:
#
#     java -classpath /users/gfisher/classes/206/lib/JVM:/users/gfisher/work/calendar/caltool/implementation/executables/JVM caltool.Main
#
#
# The following make rules use the jar utility (the Java archiver) to build two
# other forms of executable programs -- one a transportable version and another
# that is a stand-alone executable version.  These rules should be run after
# the compilation has been performed in the implementation-Makefile in
# ../../source/java/Makefile.
#


# Run the Jar utility on all of the files to build a stand-alone executable
# .jar file that includes .class files, 206 library .class files, and a
# MANIFEST file that defines the Main-Class attribute as the Main class.  The
# MANIFEST contains the following single line:
#
#	Main-Class: caltool.Main
#
# This rule builds a jar file that can be invoked stand-alone, without
# unpacking it and without linking to the external 206 library.  It is invoked
# as follows:
#
#     java -jar caltool.jar
#
# This invocation can be performed in any working directory that contains a
# copy of caltool.exe, with no required settings of the CLASSPATH
# environment variable.  The stand-alone .jar file can also be invoked from any
# other working directory simply by specifying the full path to the location of
# the .jar file.
#
jar:
		$(JAR) cmf MANIFEST caltool.jar caltool \
		    -C $(LIB206) mvp \
		    -C $(LIB206) lib206
		chmod a+x caltool.jar

# Run the Jar utility on all of the files to build a transportable program
# archive file.
# The .jar can be invoked if desired as follows:
#
#    java -classpath \
	/users/gfisher/classes/206/lib/JVM:caltool.jar \
	caltool.Main
#
# This rule builds a .jar file is primarily intended for file transfer
# purposes, not for direct invocation.  For convenient execution from a jar
# file, use the previous jar rule instead the exec rule below.
jar-simple:	$(FILES)
		$(JAR) cf caltool.jar caltool

#
# Emacs debugging string follows.  See the source dir Makefile for the most
# up-to-date emacs jdb rules.
# 
#(setq gud-jdb-directories (list  "../../source/java/caltool" "../../source/java/caltool/admin" "../../source/java/caltool/admin_ui" "../../source/java/caltool/caldb" "../../source/java/caltool/caltool_ui" "../../source/java/caltool/edit" "../../source/java/caltool/edit_ui" "../../source/java/caltool/file" "../../source/java/caltool/file_ui" "../../source/java/caltool/help" "../../source/java/caltool/help_ui" "../../source/java/caltool/options" "../../source/java/caltool/options_ui" "../../source/java/caltool/schedule" "../../source/java/caltool/schedule_ui" "../../source/java/caltool/view" "../../source/java/caltool/view_ui"))

#
# Here's the deal for defining gud-break by hand, since it doesn't look like
# the gud-def macro has enough info to deal with the package qualification:
#
#   * Goto the top of the file to get the package prefix from the package decl
#   * Define gud-break as
#	"stop at " + <package-qual> + " " +
#	    <buffer-name>-<extension> + ":" + <line-number>
#
# A more efficient alternative to searching for the package decl every time
# would be to cash it in the gud-jdb-class-source-alist or some similar alist
# structure.
#
# Here's a hand-built sample that works:
#
# (gud-def my-gud-break "stop at caltool.schedule_ui.OKScheduleAppointmentButtonListener:47" "\C-b" "My set break")

#
# Also, as a jdb todo note, the lisp function gud-jdb-marker-filter must be
# fixed so that the string it matches against is accurate wrt the current
# version of jdb.  In particular, the line number ref is of the form
# "Line=<line-number>", not of the <class>:<line-number> form assumed in the
# current version of the function.  What needs to happen is to look at the
# messages that jdb puts out when a breakpoint is hit and when single stepping
# is executed, since these are (evidently) the places where
# gud-jdb-marker-filter is invoked.  Here a couple sample outputs for
# a breakpoint being hit and a next command being executed, resp:
#
#    Breakpoint hit: thread="AWT-EventQueue-0", caltool.schedule_ui.OKScheduleAppointmentButtonListener.actionPerformed(), line=57, bci=0
#
#    Step completed: thread="AWT-EventQueue-0", caltool.schedule_ui.OKScheduleAppointmentButtonListener.actionPerformed(), line=74, bci=14