[m-dev.] For review: using alternate installation dirs

[Fergus Henderson]

On 17-Jun-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Fergus wrote:
> > On 14-Jun-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > > The first issue is what (if anything) to do about the dependency between the 
> > > `_init.c' file for the program being built and the `.init' files of the 
> > > libraries.  It is not mentioned in the `Using libraries' section of the user 
> > > manual, and similar dependencies on the `.init' files for the standard 
> > > libraries are also ignored.  However, a number of sample programs in the 
> > > extras directory declare it (references, trailed_update, clpr --- but they 
> > > probably all inherited it from the one source, whichever it was that came 
> > > first).
> > 
> > Well, the dependency is real, so ideally it should be included.
> 
> Ideally.  :-)
> 
> > The documentation in the `Using libraries' section of the user manual
> > should be updated to mention it.
> 
> OK.  Separate change?

Sounds good.

> RCS file: /home/mercury1/repository/mercury/doc/user_guide.texi,v
> retrieving revision 1.176
> diff -u -r1.176 user_guide.texi
> --- user_guide.texi     1999/06/01 09:44:47     1.176
> +++ user_guide.texi     1999/06/17 04:09:53
> @@ -739,6 +752,7 @@
>  MLLIBS = -lmypackage -lmyotherlib $(EXTRA_MLLIBS)
>  C2INITFLAGS = $(MYPACKAGE_DIR)/mypackage.init \
>                $(MYOTHERLIB_DIR)/myotherlib.init
> +%_init.c: $(C2INITFLAGS)
>  
>  # This line may be needed if @samp{--intermodule-optimization}
>  # is in @samp{MCFLAGS}. @samp{-I} options should be added for any other
> @@ -757,6 +771,8 @@
>  The extra arguments to @samp{c2init} specified in the @samp{C2INITLFLAGS}
>  variable tell @samp{c2init} where to find the @samp{.init} files for the
>  libraries, so that it can generate appropriate initialization code.
> +The following line declares the dependence of that initialization code on
> +those @samp{.init} files.
>  The @samp{-I} options in @samp{MGNUCFLAGS} tell the C preprocessor where
>  to find the header files for the libraries.

That diff looks OK.

I remember that last time this issue came up, I think Zoltan made the
good point that having %_init.c depend on $(C2INITFLAGS) was a conceptual
error, since $(C2INITFLAGS) could contain options, not just arguments
(and for consistency perhaps it should _only_ contain options).
One possible solution to that would be to define a new variable C2INITARGS
and use that instead.

> > There should also be a dependency for the final executable (or .so file)
> > on the library files (.a or .so) that it is linked with.
> 
> This seems more problematic.  (I did think about this one.)
[...]
> > The only time that it is really _crucial_ to include those dependencies
> > are when the `.init' file or the library files in question reside in
> > the same directory as the program using the library.  In that case,
> > if the dependencies aren't included, then when you type
> > `mmake realclean; mmake depend; mmake', mmake may try to build the files
> > that depend on the `.init' file before the `.init' has been created,
> > resulting in a build error.  (This was once the case with the clpr examples,
> > which used to be in the same directory as the clpr library.  The references
> > and trailed_update Mmakefiles were almost certainly copied from
> > clpr/Mmakefile.)
> > 
> > So if this is too difficult to implement, then for now I suggest that you
> > just document it with XXX comments in the appropriate places.
> 
> OK.  I'll take another look at it once I've sorted out the other stuff, and 
> if I still can't see an obvious way to do it, I will comment it as you 
> suggest.

Yep.

This situation is going to be fairly rare, and the user can always handle
it by adding the appropriate dependencies manually.  So perhaps we should
just document that they need to do that.

> > > +libraries, etc.  Note that for shared libraries to work properly, absolute
> > > +paths must be given for @samp{EXTRA_LIB_DIRS}.
> > 
> > Wouldn't it be straight-forward for `ml' to check whether the shared library
> > directories specified are absolute paths, and if not, to prepend the output
> > of `pwd' to them?
> 
> Sure.  So why doesn't it do that already?  ;-)

Good question.  Most likely because I just didn't consider that issue.

> Anyway, I can change ml to "absolutify" relative paths.  Should this be a 
> separate change?

Yep, that sounds good.

I suppose it is conceivable that there might be some situation in which
you _want_ to use relative paths for the shared library directories.
So probably there should be an ml option to retain the current behaviour.

> > Hmm.  One thing that bears thinking about is supporting path names
> > containing spaces -- on Windows, it's common practice to install
> > things into a subdirectory of the "Program Files" directory.
> > Perhaps it would be appropriate to put an XXX comment here
> > saying that it won't handle directory names containing spaces.
> > I guess the same applies to all uses of `$(patsubst ...)'.
> 
> Sure does (see above comment about patsubst, spaces and quoting).  I'm not 
> sure I'd like to try doing all this stuff without the benefit of patsubst 
> and friends.  Do you see a reasonable alternative?

No.  I just think the limitations should be documented.

> > > +++ c2init.in	1999/06/14 03:59:36
> > > @@ -41,6 +41,11 @@
> > >  		(declared in \"init.h\") that can be called from C code.
> > >  		(A more fine-grained interface is also available;
> > >  		see \"init.h\" for details.)
> > > +	-m <module>, --module <module>
> > > +		Include initialization of code listed in the file <module>.
> > 
> > The documentation here is not very clear.
> > 
> > What kind of file is `<module>' supposed to be?
> > Given just that documentation, one could easily assume
> > it is the name of a Mercury module (`.m' file).
> 
> Yes.  I borrowed the term "module" from the place the `.init' files are 
> installed: lib/mercury/modules.

That is inappropriate terminology, which arose for historical reasons;
it really ought to be renamed.  Same applies to the MERCURY_MOD_LIB_DIR
and MERCURY_MOD_LIB_MODS environment variables.
Please don't perpetuate that mistake any further ;-)

> Later I realised it was ambiguous since one 
> Mercury source file is also a module, but at the time couldn't think of a 
> better name to use.  `init-file' is probably a better choice, but the `-i' 
> option for c2init is already taken.  I don't have a problem with only having 
> long options `--init-file' and `--init-file-directory' since I'll always be 
> doing this using Mmake and never having to specify it directly, but others 
> may want a shorter option.  Any suggestions?  `-f'/`-F'?

`-f' and `-F' sound fine.

> Anyway, I've revised the documentation:
> 
>         -m <initfile>, --module <initfile>
>                 Include initialization of code listed in the \`.init' file
>                 <initfile> (if the file does not exist in the current
>                 directory it is searched for in the directories specified
>                 with the \`-M' option).

That documentation looks good, but I think `-f'/`--init-file' and
`-F'/`--init-file-directory' would be better option names.

> > From reading the source code, it looks like you're supposed to pass
> > the name of a `.init' file or a `.c' file.  What's the difference
> > between passing them on the command line as arguments and
> > passing them as `--module' options?  Why do both possibilities exist?
> 
> It should be an `.init' file.  The difference is that with `--module', the 
> extra paths are searched to find it.  I didn't think it was a good idea to 
> search the extra paths for *all* files specified on the command line.

Well, it might make sense to do it for all `.init' files on the command
line.  There won't be many of those.

So maybe you should just add one additional option, `-I'
(with something appropriate as a long name equivalent, e.g.
`--init-file-directory' or `--init-search-directory' or
`--init-file-search-directory' or something like that).

> Anyway, I'll fix all the things that are clear, and post another diff when 
> some of the other issues are resolved.  What kind of diff will you want?

This change is small enough and the differences will be large enough
that I think I'll want to do a complete rereview, so a complete diff is
probably more useful than a relative diff this time.

But when in doubt, post both kinds ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------