Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linux-distros-dev] Cross-compiling under CDT autotools 
Matt Hoosier wrote:

(sorry, copying the list this time)
On Mon, Sep 29, 2008 at 1:23 PM, Jeff Johnston <jjohnstn@xxxxxxxxxx <mailto:jjohnstn@xxxxxxxxxx>> wrote: 

    Matt Hoosier wrote:

        Hi,

        My company is interested in using Eclipse and CDT for embedded
        Linux development. In the past, we've used some other IDE's
        that have built-in knowledge of autoconf/automake, and by
        adding plugins to modify the shell environment just prior to
        executing the 'configure' and 'make' steps, been able to
        fairly easily divert the normal Autotools workflow to instead
        consult a cross-compiled sysroot directory for libraries and
        headers.

        I'm not clear on what the best way to do this is in CDT
        autotools. The code which spawns 'autoconf', for example,
        doesn't really consult any extension points to allow outside
        plug-ins the ability to customize the environment variables
        (say, CFLAGS, CPPFLAGS, LDFLAGS, ...) or the path at which the
        autoconf binary will be found. Do you have any ideas on a good
        way to do this?

    The autoconf/aclocal/automake binary paths can be set in the
    Autotools->Tools Settings found in the Project Properties.  They
    are per configuration.  The defaults are just aclocal, autoconf,
    automake.
Right. It's a little awkward to require users to routinely retarget those on every checkout of every project. Having a nature of a project which activates a plugin just to munge the path automatically would be a little more streamlined.
I can definitely see merit to adding a preference page that defaults the settings for all projects. 


    As for CFLAGS/CPPFLAGS/LDFLAGS, I'm not sure why you want to set
    these when running autoconf/automake/aclocal.  For running make,
    you can set these environment variables per configuration in the
    Project Properties.
The motivation for changing these is that embedded development typically relies on a directory where the target's headers and libraries are accumulated. You need to instruct configure to look at that directory rather than the regular (build) system's ones
So you actually mean configure instead of autoconf, correct? Processing your configure.ac file shouldn't require anything other than where the autoconf binary and m4 macros are.
Typically, it's configure's "job" to hook up your target libraries and headers as well as to appropriately set any flags it needs to perform tests. I can't say how common your situation is or whether your configure file just isn't properly set up. It certainly doesn't apply to any of the sourceware gnu projects I am familiar with. For example, to build newlib on mn10300-elf, I simply add my mn10300 toolset to the PATH environment variable in C/C++ Build->Environment and I specify target mn10300-elf in the C/C++ Build->Settings->Tool Settings->configure Platforms dialog. Since this is per-configuration I have one configuration per target.
To handle your particular situation, perhaps we could enhance the code to handle environment variables ahead of the command specification (e.g. change the configure command in the Tool Settings dialog to be "LDFLAGS=xxx configure" instead of just configure) and have the code in autotools strip these off and add them as environment variables for the command execution. I think that would solve the problem. 

-- Jeff J.
Thanks, 

Matt

Back to the top