| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
well over a year now. Sorry. :-(
|
|
many packages used to use ${PAX}. Use the common way of directly calling
pax, it is created as tool after all.
|
|
their files via a custom do-install target.
|
|
|
|
|
|
|
|
|
|
PKGREVISION.
|
|
|
|
|
|
|
|
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.
|
|
should fix problems seen in latest bulk-build
|
|
|
|
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.
|
|
|
|
- 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
|
|
|
|
until all JVMs are converted. Noted by snj.)
|
|
|
|
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).
|
