Matt Hoosier wrote:
(sorry, copying the list this time)
On Mon, Sep 29, 2008 at 1:23 PM, Jeff Johnston <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
_______________________________________________
linux-distros-dev mailing list
linux-distros-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linux-distros-dev
