linux support

[YahooArchive]

I'd suggest

/usr/share/coridium-XX/bin -- apps
/usr/share/coridium-XX/conf -- ini
/usr/share/coridium-XX/docs -- docs

apps: /usr/share/coridium-XX/bin
symlink the apps to /usr/bin
This way you can opt to keep multiple versions under /usr/share/coridium-v1/bin,
-v2/bin, etc, yet the common user link in /usr/bin is always the same. Where XX
is a version, or not, user can decide (its called a relocatable rpm).

Minor suggestion is to use a Starkit to pack the tcl apps?
This way you are not dependant on any Tcl installation.
But you have to build one for each platform, win32, linux, mac.

I am reasonably sure that USB->serial adapters work in linux.
Are you using the Tcl trick to enum serials > 4 ???

I can help you with an rpm build.

Just email me.

[YahooArchive]

Please don't distribute Ubuntu files using RPM. .deb files are native
to Ubuntu, Debian and other similar distros.

Jim.

[YahooArchive]

Right, I use those things so much I forgot they are different forms.

You can install rpms on ubuntu, you just have to install some other stuff.
Problem then, is that the software updater doesn't know about rpms.

Once one type is working the other should not be hard to create.

[YahooArchive]

Thanks Jim-

The first set of files will probably be just that, a set of files. Been
fighting minor inconveniences like the machine I planned to do this on decided
to head to the big Intel graveyard in the sky.

I can do the googling, but if you point me at some simple examples that would
speed my effort.

Do installations of all executable files really go to /usr/bin?
or just the "launch" executable?
or change of paths for every installation?
or ... (seems to me like /usr/bin would get pretty crowded.

Like I said we are just casual Linux users.

[YahooArchive]

Take a look at jmroberts5's first email in this thread. It appears to
be a reasonable way to organize your files.

Any executable files you would reasonably expect a user to execute
directly may be placed in /usr/bin or /usr/local/bin. Any executable
files that are normally executed only via scripts or indirectly can be
most anywhere you want to put them with these recommended policies.
Don't put anything in /usr/bin that you don't want a user to directly
execute. Put this indirectly referenced binaries in a "bin" directory.
The latter rule (loosly defined, there are no hard rules) makes it easy
for people to understand what's in your file tree.

As far as making a package, I would strongly encourage you to use the
gnu utilities to construct your "compile and install" set of files.
While there is a bit of a learning curve to it, once you get it
packages, it's very easy to upgrade and make minor tweaks.

This is about the best quick introduction to the gnu auto utilities I've
seen. It's dated so following it's suggestions explicitly may not work
well, but it's a good overall discussion of how things work.

If you give me an idea of how your sources are organized and what your
compile and load steps are like and what files will be generated from
those steps and what additional packages are to be included in the
eventual package, I'll be glad to give you some help in constructing the
necessary files. Obviously the sources are proprietary but I'd be glad
to sign a non disclosure agreement or you can just give me file names.

As far as the creation of the .deb or .rpm packages, Once you have your
files such that "make install" will put the files where you want them, I
can show you how to easily create either package.

Jim.

[YahooArchive]

There's actually a standard for Linux:

http://en.wikipedia.org/wiki/Filesystem ... y_Standard

HTH,

Jeff
Happiness is - positive intake manifold pressure.

[YahooArchive]

Alas the 'standard' is so vague as to be almost useless.
It can be followed only in the broadest terms.

After looking at the Coridium files, I suggest merely packing everything up
under something XYZ/Coridium/(same as now in win32 subfolders).

XYZ can be:

/opt
/usr/local/share
/usr/share

then simply add a path element to point to /XYZ/Coridium/bin/
export PATH=$PATH:/XYZ/Coridium/bin

A *.tgz will work fine in this instance.

Bruce you are using the tcl to run the gcc compiler right? I don't think theres
any platform specifics is there? I'll look again.

Looks to me like the biggest headache is the windows chm help file.
Can you port that to a pdf?

[YahooArchive]

OK, I know there's a lot broken (like edit menu trying to use Notepad) and its a
zip file and not tar

But, this does run on my Ubuntu system, even compiling our big test cases.

Only 4 files needed, keep them in the same directory. You can find them in the
Files section of this forum BASICtools4linux.zip

And for now I have to start it by

wish BASICtools.tcl

It gives us a talking point as to where to go from here.

... and its time to go out and have a Margarita on the beach.

[YahooArchive]

Definitely!

Thanks for all your effort toward making a Linux version.
May I take it that you are focusing on Ubuntu as the
Linux version you're going to support?

Jeff

[YahooArchive]

> May I take it that you are focusing on Ubuntu as the
> Linux version you're going to support?

Not really wedded to Ubuntu, but as its working here, I'll probably stick with
it unless there's a good reason to switch.

2 of the files are .tcl so its pretty portable (based on 8.4 which is most
common out there.

The other 2 are compiled with gcc. Someone told me the switch to make that more
portable among x86 systems, but I couldn't find that in my old emails. The
ARMbasic compiler we'll have to compile, the bpp pre-processor was contributed
by Tom, files available here in the forum.

Linux-arm-basic-pp-20080828-2.tgz

(1.48 MiB) Downloaded 1406 times