mirror of
https://git.FreeBSD.org/ports.git
synced 2024-11-24 00:45:52 +00:00
Change this file to describe what it is, instead of how to write your
own interviews application. It's only one line long (I couldn't find any suitable paragraph I can cut and paste from in the source tree) but at least it is a description of the port now. Closes PR ports/1517.
This commit is contained in:
Satoshi Asami
parent
ded7a416a3
commit
48a047046c
Notes:
svn2git
2021-03-31 03:12:20 +00:00
svn path=/head/; revision=5812
@ -1,155 +1 @@
|
||||
* How to use InterViews
|
||||
|
||||
After installation, you can start using InterViews by putting the following
|
||||
lines in your .cshrc:
|
||||
|
||||
setenv CPU FREEBSD
|
||||
setenv MANPATH $MANPATH:/usr/local/interviews/man
|
||||
setenv PATH $PATH:/usr/local/interviews/bin/$CPU
|
||||
|
||||
Once you have /usr/local/interviews/bin/$CPU in your PATH, you can use the
|
||||
InterViews script "ivmkmf" to generate Makefiles for your own
|
||||
InterViews applications. You have to write an Imakefile first, but
|
||||
you can do that by copying one of the Imakefiles in iv/src/bin and
|
||||
replacing the filenames with the names of your application's source
|
||||
files. Saying "ivmkmf" will generate a Makefile that contains the
|
||||
appropriate -I and -L flags for using the InterViews includes and
|
||||
libraries when building your application.
|
||||
|
||||
* How to write an Imakefile
|
||||
|
||||
The easiest way to write an Imakefile is to start with a copy of a
|
||||
similar Imakefile and modify it. If you use only 3.1 classes, you can
|
||||
copy alert's Imakefile. If you use both 3.1 and 2.6 classes, you can
|
||||
copy doc's Imakefile. If you use only 2.6 classes, you can copy dclock's
|
||||
Imakefile. If you use the Unidraw library, you can copy idraw's
|
||||
Imakefile. Reading the config files to understand how the rules are
|
||||
defined will also help if you need to do anything complicated.
|
||||
|
||||
Some make variables are reserved for your application's use. You can
|
||||
compile your application with special compiler flags, defines,
|
||||
includes, linker flags, or libraries by setting APP_CCFLAGS,
|
||||
APP_CCDEFINES, APP_CCINCLUDES, APP_CCLDFLAGS, or APP_CCLDLIBS in your
|
||||
Imakefile. You can make your application depend on libraries by
|
||||
setting APP_CCDEPLIBS.
|
||||
|
||||
You can cause your application to be linked with InterViews libraries
|
||||
bu using one and only one of the macros Use_libInterViews(),
|
||||
Use_libUnidraw(), and Use_libgraphic(). Both libUnidraw and
|
||||
libgraphic depend on libInterViews so saying Use_libUnidraw() or
|
||||
Use_libgraphic() makes saying Use_libInterViews() unnecessary. You
|
||||
cannot say both Use_libUnidraw() and Use_libgraphic() because
|
||||
libUnidraw and libgraphic conflict with each other. All of these
|
||||
macros also add -lXext -lX11 -lm to CCLDLIBS for you.
|
||||
|
||||
If your application uses classes from the "old" InterViews 2.6,
|
||||
Unidraw, or graphic libraries, you should use the macro Use_2_6() as
|
||||
well as one of the macros Use_libInterViews(), Use_libUnidraw(), or
|
||||
Use_libgraphic(). Many 3.1 classes have the same names as 2.6 classes
|
||||
so the shorter names are reserved for the 3.1 classes and the 2.6
|
||||
classes' names are prefixed with "iv2_6_". The macro Use_2_6() allows
|
||||
you to use the classes' shorter 2.6 names instead of their real names
|
||||
and their shorter include paths (<InterViews/*.h>) instead of their
|
||||
real include paths (<IV-2_6/InterViews/*.h>. If you want to use
|
||||
both 3.1 and 2.6 classes in the same application, you will
|
||||
need to omit Use_2_6() and use the 2.6 classes' real names and
|
||||
include paths.
|
||||
|
||||
You can use the macro ComplexProgramTarget(dest) to build a program.
|
||||
The parameter specifies the name you want the program to have after
|
||||
it's installed. The make variable $(AOUT), which defaults to "a.out,"
|
||||
specifies the name the program will have when it's built. The make
|
||||
variable $(OBJS), which defaults to "*.o," specifies the list of
|
||||
object code files which must be linked together. You don't have to
|
||||
define either $(AOUT) or $(OBJS) in the Imakefile because the
|
||||
generated Makefile will assign default values to them. You don't have
|
||||
to define the list of object files in $(OBJS) because the Imakefile
|
||||
will generate dependencies between the program and its object code
|
||||
files of the form
|
||||
|
||||
a.out:
|
||||
$(CC) $(OBJS)
|
||||
|
||||
a.out: a.o
|
||||
a.out: b.o
|
||||
a.out: c.o
|
||||
|
||||
which is equivalent to the traditional form
|
||||
|
||||
a.out: a.o b.o c.o
|
||||
$(CC) $(OBJS)
|
||||
|
||||
You will define these dependencies automatically when you use the
|
||||
macros MakeObjectFromSrc(file) and MakeObjectFromSrcFlags(file, flags)
|
||||
for each source file in the program. Each source file must have its
|
||||
own rule (hence the macro) because the implicit make rule cannot
|
||||
compile source files which are not in the current directory. However,
|
||||
you won't have to specify the name of the source file again in any
|
||||
other place in the Imakefile.
|
||||
|
||||
You should surround the Imakefile with the following lines,
|
||||
|
||||
#ifdef InObjectCodeDir
|
||||
<contents>
|
||||
#else
|
||||
MakeInObjectCodeDir()
|
||||
#endif
|
||||
|
||||
so that saying "make Makefiles" will create a subdirectory in which to
|
||||
put the object code files. You do not have to use these lines, but if
|
||||
you do not you will not be able to build optimized, debuggable, and
|
||||
non-shared object code files alongside of each other in separate
|
||||
subdirectories. You also will not be able to build object code files
|
||||
for different machine architectures alongside of each other in
|
||||
separate subdirectories. On the SPARCstation, such object code
|
||||
directories will have the names SUN4, SUN4.debug, and SUN4.noshared
|
||||
(the latter two will be created only if you use a special make
|
||||
command, see below).
|
||||
|
||||
After you finish writing your Imakefile, saying "ivmkmf" will generate
|
||||
the corresponding Makefile. Then you can say "make Makefiles; make
|
||||
depend; make all" to build your program. If you make a new change to
|
||||
the Imakefile, all you have to do is to say "make Makefile"---you
|
||||
don't have to use "ivmkmf" again.
|
||||
|
||||
Saying "make Makefiles.debug" and/or "make Makefiles.noshared" will
|
||||
create the special object code subdirectories and saying "make
|
||||
depend.debug", "make depend.noshared", "make all.debug", or "make
|
||||
all.noshared" will build in them just like the normal subdirectories.
|
||||
Note that the Makefile will provide the "make *.noshared" targets only
|
||||
if you're on a computer which has shared libraries (currently we
|
||||
support only SunOS shared libraries).
|
||||
|
||||
If you write a Makefile by hand instead of writing an Imakefile,
|
||||
you'll have to specify everything that make needs to know. For
|
||||
example, you'll have to specify the -I and -L flags needed to use the
|
||||
InterViews includes and libraries when compiling your application.
|
||||
You'll also have to specify any extra flags that your system may need
|
||||
even though you may have to change them when building on a different
|
||||
system (when you use an Imakefile, the platform-specific X11 .cf file
|
||||
specifies these flags for you so they don't have to be in the
|
||||
Imakefile).
|
||||
|
||||
* How to stay tuned
|
||||
|
||||
If you have a bug report, please send it to
|
||||
|
||||
interviews-bugs@interviews.stanford.edu
|
||||
|
||||
If you have any questions or problems, please post them in the USENET
|
||||
newsgroup
|
||||
|
||||
comp.windows.interviews
|
||||
|
||||
If you do not have access to news and you wish to be on the InterViews
|
||||
mailing list which is gatewayed with comp.windows.interviews, send a
|
||||
request to
|
||||
|
||||
interviews-requests@interviews.stanford.edu
|
||||
|
||||
The mailing list alias is
|
||||
|
||||
interviews@interviews.stanford.edu
|
||||
|
||||
Please post to only the newsgroup or only the mailing list but not
|
||||
both since whatever you post in one will appear in the other too.
|
||||
Interviews is a toolkit with lots of nice utilities (like idraw).
|
||||
|
||||
Loading…
Reference in New Issue
Block a user