diff options
author | adam <adam@FreeBSD.org> | 1994-09-24 23:54:12 +0800 |
---|---|---|
committer | adam <adam@FreeBSD.org> | 1994-09-24 23:54:12 +0800 |
commit | e86acacb666e9b418f3c0f02bcae180078f46ea2 (patch) | |
tree | 074fc7edeebcf5eec4b47f168ea3bfb442649345 /x11-toolkits | |
parent | a9f39fe62f43b5d874730d8d9f10295057729c9d (diff) | |
download | freebsd-ports-gnome-e86acacb666e9b418f3c0f02bcae180078f46ea2.tar.gz freebsd-ports-gnome-e86acacb666e9b418f3c0f02bcae180078f46ea2.tar.zst freebsd-ports-gnome-e86acacb666e9b418f3c0f02bcae180078f46ea2.zip |
keyboard bounce
Diffstat (limited to 'x11-toolkits')
-rw-r--r-- | x11-toolkits/iv/pkg-descr | 155 |
1 files changed, 155 insertions, 0 deletions
diff --git a/x11-toolkits/iv/pkg-descr b/x11-toolkits/iv/pkg-descr new file mode 100644 index 000000000000..a3de1d83a592 --- /dev/null +++ b/x11-toolkits/iv/pkg-descr @@ -0,0 +1,155 @@ +* 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. |