chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of va


From: Oleg Kolosov
Subject: Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables
Date: Sat, 14 Jun 2014 19:45:57 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 06/13/14 10:38, Peter Bex wrote:
> On Fri, Jun 13, 2014 at 01:53:51AM +0400, Oleg Kolosov wrote:
>> On 06/12/14 23:56, Peter Bex wrote:
>> You can look for hints in commonly used build systems implementations.
>> I'm not sure how autotools handle this, but CMake have quite elaborate
>> rules, see:
>> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:find_path
> 
> Thanks, but I think this is for locating existing files rather than
> installing programs into locations.  This could be useful too if we want
> to supply better defaults in other places.
> 
>> BTW, "standard" environment variable for include path is called just
>> "INCLUDE".
> 
> I think you've mixed up two variables: I think here INCLUDE is the
> include _path_ as searched by the C compiler when building, whereas
> INCLUDEDIR is the directory into which to copy include files when
> installing.  If you look further down that page, under GNUInstallDirs,
> it says this:
> 
> INCLUDEDIR       - C header files (include)
> 
> This is what I've seen most as it's the GNU convention, which autotools
> use.  NetBSD's pkgsrc sets a few environment directories in bsd.pkg.mk,
> and they call it INCSDIR:
> http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/mk/bsd.pkg.mk
> Some libraries from NetBSD's base system use INCDIR, like CHICKEN (but
> there it means the base include dir, unlike in CHICKEN).  I think we
> should support whatever is the most common, and I think that's
> INCLUDEDIR.
> 

Sorry, looks like I've not read your original mail thoroughly enough. By
the way, the note about GNUInstallDirs remind me about an issue I had
with them when compiling Chicken along with few other stuff for
cross-toolchain: various Linux distributions have different conventions
about the placement of shared libraries. In particular, most place them
in lib64 and lib32 when compiled for corresponding arch. Chicken places
everything in lib by default, which works as long as you have
appropriate symlink in place which is AFAIK is kind of workaround and
might not be the case on every system. For example, Debian have more
interesting convention (don't remember if they have this symlink),
various SDKs with the provided Linux rootfs are even more funny. When
compiling cross-chicken matters get more interesting because we can not
detect the properties of the target platform. So, does it make sense to
allow user to override every path individually with build configuration?

>> Actually, when working with cross Chicken, only one C compiler is needed
>> at the given build invocation.
> 
> No, you need *two* C compilers when working with a cross-CHICKEN, because
> you can install extensions on the host.  This is necessary for syntax
> extensions like "matchable", for example: those run inside the compiler,
> on the host system, when compiling a program for the target system.
> Compare chicken-install's -host and -target options.

You are right, of course. I meant, in practise, our application uses a
ton of internal Chicken modules, and I never bothered with installing
them for host and just use cross-chicken to generate C files and compile
them with cross-compiler alongside other sources. You still need to pass
correct include paths from module build dirs to handle
cross-dependencies. All in all, works fine so far.

And to atone for off-topic here I have a proposal. Leave current
Makefiles as it is without breaking anything and pump all desired
features to the new CMake based build. I've already migrated our
internal project: we use Linux cross-compilation, modules, embedded
files, a lot of FFI, even tried type files, so, feature-wise, it is
quite capable already. Native Windows support is almost there. I need to
cleanup few things before presenting it for review however.

I fear that necessity to adjust build scripts twice will bring
frustration to possible early adopters.

-- 
Regards, Oleg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]