summaryrefslogtreecommitdiff
path: root/devel/jgrasp
AgeCommit message (Collapse)AuthorFilesLines
2005-11-04Removed unknown JVM "jdk13".rillig1-2/+2
2005-06-16Create directories before installing files into them.jlam1-1/+2
2005-06-01Massive cleanup of buildlink3.mk and builtin.mk files in pkgsrc.jlam1-2/+2
Several changes are involved since they are all interrelated. These changes affect about 1000 files. The first major change is rewriting bsd.builtin.mk as well as all of the builtin.mk files to follow the new example in bsd.builtin.mk. The loop to include all of the builtin.mk files needed by the package is moved from bsd.builtin.mk and into bsd.buildlink3.mk. bsd.builtin.mk is now included by each of the individual builtin.mk files and provides some common logic for all of the builtin.mk files. Currently, this includes the computation for whether the native or pkgsrc version of the package is preferred. This causes USE_BUILTIN.* to be correctly set when one builtin.mk file includes another. The second major change is teach the builtin.mk files to consider files under ${LOCALBASE} to be from pkgsrc-controlled packages. Most of the builtin.mk files test for the presence of built-in software by checking for the existence of certain files, e.g. <pthread.h>, and we now assume that if that file is under ${LOCALBASE}, then it must be from pkgsrc. This modification is a nod toward LOCALBASE=/usr. The exceptions to this new check are the X11 distribution packages, which are handled specially as noted below. The third major change is providing builtin.mk and version.mk files for each of the X11 distribution packages in pkgsrc. The builtin.mk file can detect whether the native X11 distribution is the same as the one provided by pkgsrc, and the version.mk file computes the version of the X11 distribution package, whether it's built-in or not. The fourth major change is that the buildlink3.mk files for X11 packages that install parts which are part of X11 distribution packages, e.g. Xpm, Xcursor, etc., now use imake to query the X11 distribution for whether the software is already provided by the X11 distribution. This is more accurate than grepping for a symbol name in the imake config files. Using imake required sprinkling various builtin-imake.mk helper files into pkgsrc directories. These files are used as input to imake since imake can't use stdin for that purpose. The fifth major change is in how packages note that they use X11. Instead of setting USE_X11, package Makefiles should now include x11.buildlink3.mk instead. This causes the X11 package buildlink3 and builtin logic to be executed at the correct place for buildlink3.mk and builtin.mk files that previously set USE_X11, and fixes packages that relied on buildlink3.mk files to implicitly note that X11 is needed. Package buildlink3.mk should also include x11.buildlink3.mk when linking against the package libraries requires also linking against the X11 libraries. Where it was obvious, redundant inclusions of x11.buildlink3.mk have been removed.
2005-04-04USE_X11= yesjschauma1-1/+2
should fix problems seen in latest bulk-build
2005-02-23Add RMD160 digests.agc1-1/+2
2004-08-27Replace RPATH_FLAG with LINKER_RPATH_FLAG and COMPILER_RPATH_FLAG,jlam1-2/+2
which are the full option names used to set rpath directives for the linker and the compiler, respectively. In places were we are invoking the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is inserted in case the flag is a word, e.g. -rpath. The default values of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the compiler that you use. They may be overridden on a ${OPSYS}-specific basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG, respectively. Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.
2004-07-14Fix PLIST for 1.7.0 (hi jschauma!)wiz1-4/+72
2004-06-05Update jGRASP to version 1.7.0. Changes/bug fixes since 1.6.4:jschauma2-7/+7
- Some compatibility issues when running under Sun Java 1.5 beta are resolved. There probably are other problems. - Some characters with valid font mappings, such as curly double quotes on Windows, may show up as hex codes in the CSD and Run I/O windows. - After doing a "find" in the Run I/O window, the cursor may move into the output region, which will allow editing of previous output, and may lead to other problems. - If a "clear" or "File / Open" is done from a CSD window, settings for the previous file will not be saved, and the file will not be added to the "Recent Files" menu. - If text above the screen which contains all bookmarks or breakpoints is cut, the on-screen text will not be shifted, and the display may be temporarily corrupted. - In the jar and documentation generating tools, some of the files are not stored as relative, and will become absolute when jGRASP is restarted. - This means that if a project is move, the jar target file and documentation target directory will not move with it, and will have to be reset. - Command paths for compile, run, etc. are not quoted on Windows. This can cause "C:\Program Files\etc\etc\something.exe" to fail if the file" C:\Program" exists, for example. - Selecting both files and the project in the project tab and using "Open" from the popup menu will cause a harmless crash, and some or all of the files may not open. - Switched default debug attacher from shared memory to socket on Windows NT/2000/XP, since the shared memory attacher tends to lock up under Sun Java 1.5 beta. - In a CSD window, undoing edits on a saved file then doing an equal number of edits will mark the file as unmodified, even though it is modified. This may cause unexpected behavior, and lost edits. - In the debugger and workbench, doubles and floats with NaN values will always be shown in red text (indicating change) even when the values were previously NaN. - In 1.6.6, timeouts were added to kill the debugger if it did not respond for 10 seconds. This proved to be a problem because of modal dialogs. If jGRASP locks up while using the debugger or workbench, you should kill the target process externally using Task Manager on Windows, "kill" on UNIX/Linux, etc. - Multiple projects can be open simultaneously. - Workspaces can be saved and loaded. - Project level run and debug commands are available on the UML window. - Methods can be invoked while debugging from within the workbench. - Numerous other small features were added, menus reorganized, etc. - The default project has been eliminated, and users can now use jGRASP "projectless". - Expression evaluation in the Java debugger now supports varargs and autoboxing/unboxing. - Values in the Java debugger can now be dragged to anywhere and released to pop up a "view by name" viewer. - Shortcut operators -- && || ?: -- can now be used in eval expressions, method arguments, etc. in the integrated Java debugger. - Long lines in PostScript printouts may contain added spaces. - UML print preview fails (display is incorrect) when the size of the previewed pages is smaller than a certain size. - Text can be dragged and dropped into compile messages window and jGRASP messages window, which can result in mangled output. - Debug "eval" gives incorrect results for == and != when applied to Objects. - Printing may crash when part of the text is folded. - Closing the UML window while compiling from the UML window causes a crash - Paste of plain text was broken in Beta 3 (rtf still worked though). - For the Java debugger, watch markers on inaccessible fields are the same color as the field marker instead of black, which can make them hard to see - CLASSPATH is passed to appletviewer commands - Detailed messages are now given when a compiler or program fails to run on UNIX/Linux - A bug that was causing an occasional crash at start-up was fixed
2004-06-03Add jdk14 (and in some cases jdk13)abs1-2/+2
2004-05-15Revert part of the previous change (we cannot define USE_BUILDLINK3,kristerw1-4/+1
until all JVMs are converted. Noted by snj.)
2004-05-15bl3ifykristerw1-2/+6
2004-01-09Initial import of jGRASP:jschauma4-0/+211
jGRASP is a medium-weight development environment, created specifically to provide automatic generation of software visualizations for the purpose of improving the comprehensibility of software. jGRASP is implemented in Java, and runs on all platforms with a Java Virtual Machine (Java version 1.3 or higher).