Environment setup script

The compiler tools do not use the environment variables MAKEFLAGS or LD_LIBRARY_PATH.  So it doesn't make sense for an associated script to modify those variables.  The only one left is PATH.  Should the compiler tools come with a script that only adds to the PATH?

Thanks and regards,

-George

I imagine TI prefers not to do this because it can be difficult to anticipate what a customer's exact build setup will be - in case of a name collision, using a "standard" env setup script can actually introduce more problems than it solves.

That being said, if something like this were added, it would be nice if the script also appended the location of the CGT man pages to MANPATH.

> I imagine TI prefers not to do this because it can be difficult to anticipate what a customer's exact build setup will be - in case of a name collision, using a "standard" env setup script can actually introduce more problems than it solves.

I do not get what you mean by that. It is for knowing the customer's installation set up. It is likely not accidental certain other embedded environments do the same. It is meant for aiding the setup for third-party projects, especially when the toolchain does not support the "--sysroot" path like in this particular case.

Will I need to update the target environment root path every time I update or install the new version of the environment because of the version change in the directory? I would not personally like to do that. I would like to run the environment script and that figures out the low-level details.

I do not follow.

Those variables would be set up by the customers, and the task would be up to them to create such a simple script instead of created once by TI. No, it is not just the PATH, it is everything in there, most importantly the target root PATH.

Could you please open a bugreport for this unless you get a --sysroot like option implemented which would also be good, but probably not fully after all?

Thank you..

Kurt Landenberger said:

it would be nice if the script also appended the location of the CGT man pages to MANPATH

There are no CGT man pages.   Instead, the compiler manuals are supplied in the \doc directory.  They are also online here.

Thanks and regards,

-George

Laszlo Papp said:

I imagine TI prefers not to do this because it can be difficult to anticipate what a customer's exact build setup will be - in case of a name collision, using a "standard" env setup script can actually introduce more problems than it solves.

I really do not get what you mean by that. It is exactly for knowing the customer's installation set up. It is not accidental certain other embedded environments do the same. It is exactly for aiding the setup for third-party projects, especially when the toolchain does not support the "--sysroot" path like in here.

[/quote]

Unconditionally appending to system variables like PATH, LD_LIBRARY_PATH, etc. does help developers get a build up and running fast. I would be cautious of advising everyone to use such a script as those variables may potentially contain anything (consider a careless developer who runs the env setup script for one toolchain version followed by the other).

Will I need to update the target environment root path every time I update or install the new version of the environment because of the version change in the dictionary? Nope, I would not like to do that. I would actually like to run the environment script and that figures out the low-level details.

I wouldn't call the contents of any variable that directly affects your compilation and link process a "low-level detail".

George Mock said:

it would be nice if the script also appended the location of the CGT man pages to MANPATH

There are no CGT man pages.   Instead, the compiler manuals are supplied in the \doc directory.  They are also online here.

[/quote]

Do the DSP tools not provide man pages? The TI MSP430 tools at least include them in $CG_TOOL_ROOT/man.

Unconditionally appending to system variables like PATH, LD_LIBRARY_PATH, etc. does help developers get a build up and running fast. I would be cautious of advising everyone to use such a script as those variables may potentially contain anything (consider a careless developer who runs the env setup script for one toolchain version followed by the other).

I still do not get what you are talking about. You are mentioning a non-existent problem that has never caused any issues at large on other platforms the last 5-6 years at least. In fact, usually developers have a session for the build environment setup in which case your argument is mostly hypothetical.

I wouldn't call the contents of any variable that directly affects your compilation and link process a "low-level detail".

It *is* a low-level detail because all you are interested in, is getting the variables up and running.

How can third-party projects handle the TI toolchain path? Have you ever tried? I have tried to add support myself to at least two projects, and it is not so cool as it is now. They might all require a *separate* variable in worst case scenario to set up cause there will be *no* standard. Do you think people are not annoyed if they have to set up a variable for each downstream project?

Kurt Landenberger said:

Do the DSP tools not provide man pages?

I apologize.  I was incorrect to say there are no man pages.  There are no man pages supplied with the Windows distribution.  But the Linux distribution does include man pages.  Thus, it is reasonable to suggest that installing the compiler on Linux causes the MANPATH variable to be updated.

Thanks and regards,

-George