[Elphel-support] Source init_env in current working directory

Robbert rma at vmsys.com
Tue Dec 1 18:59:48 PST 2009


To me or other non-Elphel people, normally the working directory is a
subdirectory.

You do not start with "make update"? Updates are happen rather frequently.
   For new features test, yes, but for product env.  I prefer to stick to
stable version.

Beside it takes too long to open Elphel project in KDevelop.

How long? I've seen it takes time to open the first time, but then it is
rather fast.
   On Thinkpad T41, it need about 35 seconds. I tried to start KDevelop on
RedHat twice, it almost killed the server, I have to restart the server.

 I would rather go to my working directory directly, modify the source,
compile it and then transfer it to camera for test.

If it is completely separate project, that does not need to communicate with
existent software, use header files - then I would agree. But I find easier
to find related definitions, functions when the project is in KDevelop with
ctags and other features.

    Yes, that’s true, once the project is opened; it’s a better env than
command line.

Anyway it won’t bother me as I can always overwrite the original init_env
file.

Again - that is correct if you do not do "make update" - after each revision
number change you'll need to re-run configure and init_env wil be
regenerated.




 

 

Robbert


  _____  


From: elphel at gmail.com [mailto:elphel at gmail.com] On Behalf Of Andrey
Filippov
Sent: Tuesday, December 01, 2009 4:53 PM
To: Robbert; Sebastian Pichelhofer


Cc: support-list at support.elphel.com
Subject: Re: Source init_env in current working directory

 

Robbert,


We inherited this script from Axis SDK and I'm not sure this change will
have some side effects. And normally "working directory" is the same as
$AXIS_TOP - many make targets are only defined when you start from there (I
usually start with "make update"). In KDevelop you can start from you
application directory and select "Compile" from the top menu - init_env will
be sourced automatically.

So it seems safe to make such change, but I'm not really sure.

Andrey 

On Mon, Nov 30, 2009 at 10:25 PM, Robbert <rma at vmsys.com> wrote:

In that case, we need to modify the “function†, do we?

 

Robbert


  _____  


From: elphel at gmail.com [mailto:elphel at gmail.com] On Behalf Of Andrey
Filippov
Sent: Tuesday, December 01, 2009 4:07 PM
To: Robbert
Cc: support-list at support.elphel.com
Subject: Re: Source init_env in current working directory

 

Robbert,

init_env is not part of the project - it is generated by 

 make init_env


And the top Makefile is also generated (most code is in "functions")

Andrey

On Mon, Nov 30, 2009 at 9:25 PM, Robbert <rma at vmsys.com> wrote:

Hi Andrey,

 

When you go straight to your working directory and source the init_env there
(eg. “source ../../../init_env†  OR  “source
symbol_link_file_of_init_env†), the script doesn’t work
properly. 

I modified the file to make it work better, hope it will help.

 

Robbert

===========================================

 

filename=`readlink -f ${BASH_SOURCE[0]}`

export AXIS_TOP_DIR=`dirname $filename`

echo "Prepending \"$AXIS_TOP_DIR/tools/build/bin\" to PATH."

export PATH="$AXIS_TOP_DIR/tools/build/bin:$PATH"

echo "Prepending \"/usr/local/cris/bin\" to PATH."

export PATH="/usr/local/cris/bin:$PATH"

export AXIS_KERNEL_DIR="$AXIS_TOP_DIR/os/linux-2.6"

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.426 / Virus Database: 270.14.87/2535 - Release Date: 11/30/09
21:05:00

 

No virus found in this incoming message.
Checked by AVG - www.avg.com

Version: 8.5.426 / Virus Database: 270.14.88/2537 - Release Date: 11/30/09
21:05:00

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.426 / Virus Database: 270.14.88/2537 - Release Date: 12/01/09
19:32:00

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20091202/df885385/attachment-0002.html>


More information about the Support-list mailing list