Keith Thompson wrote:
> santosh <santosh.k83@[EMAIL PROTECTED]
> writes:
>> jacob navia wrote:
> [...]
>>> I am changing the compiler now to use /usr/local/lcc, and added
>>> following paths to the include search path:
>>>
>>> /usr/local/lcc/include
>>
>> This should almost certainly be /usr/local/include/lcc/
>>
>>> /usr/local/include
>>> /usr/include/lcc
>>> /usr/include
>>
>> In my opinion you should neatly encapsulate lcc's headers in it's
>> own 'lcc' sub-directory under the system include directories. That
>> way you don't need to bother with /usr/include/ and
>> /usr/local/include/
>
> My own preference would be to put the entire installation under a
> single user-specifiable directory. For example, if I install it with
> a prefix of "/usr/local/lcc", I'd have
>
> /usr/local/lcc
> /usr/local/lcc/bin
> /usr/local/lcc/lib
> /usr/local/lcc/include
>
> and so forth.
<snip>
Yes. Now that I think about it this might be a better scheme,
particularly during the early phases of the software.
Jacob should write his implementation in such a way that it searches for
it's headers and libraries in a user controllable manner, preferably
via a couple of environment variables like for example LCC_INCLUDE and
LCC_LIB, and of course, also via switches on the command-line.
Right now, he seems to have hardcoded the paths into his main
executable.
If the environment variables have not been set, the compiler should try
to look into the 'include' and 'lib' directories below the directory
it's placed in.
If that fails too, then the compiler could try to
read /usr/include/lcc/, /usr/lib/lcc/, /usr/local/include/lcc/
and /usr/local/lib/lcc/.
|
