Hello Michael,
Thank you for your detailed replies. Some more notes:
> -re: requiring -debug or -release on the command line cvicc is built
> using the same source as the comple.exe utility from Windows. Neither
> tool reads the workspace .cws file which is where the debug versus
> release configuration info is stored. The Windows version was
> envisioned to be a tool used in an automated release build where you
> would not want to pick up the environments last saved configuration,
> you would most likely want to specify on the command line which to
> build.
Makes sense I guess. It's certainly not an important issue.
> -re: the -rebuild option The -rebuild is used to prevent the cvicc
> from doing a dependency check, possibly because the file dates have
> changed. A prime use case would be if you used the same physical
> source tree on a dual boot linux/Windows machine; after you built on
> Windows and then rebooted into linux, the object files look up to
> date, but they are Windows format files that cvicc won't recompile
> which then get passed to the linux linker which has no idea what the
> object files are and generates link errors.
I actually use a samba or nfs share (depending on which server I'm on). So
it's exactly as you describe: write, compile and test on windows, then
compile and test on Linux. Rebuild is necessary as you describe to separate
both linkers. With some feng shui I could mount a cvibuild.AcqEDM on Linux
on top of the physical on to keep both separate, but it's not worth it.
> -re: [Shift][Tab] bug In general this works, what distribution/window
> manager are you using?
Scientific Linux 4 something with kernel 2.6.9-42.0.10.EL (a variant of Red
Hat)
> -re: GetDiskSpace link bug The toolbox function GetDiskSpace is
> implemented on top of the Win32 SDK function GetDiskFreeSpaceEx and is
> located within a ifdef for _NI_mswin32_.
I suspected this much. I rely on several toolbox.fp functions. Is there a
list of the non-linux compatible ? How are they supposed to behave when not
compatible ? I guess they are planned for inclusion in the future. How will
that work out ?
> -re: UInt64Type The definition for this type is in toolbox.h inside a
> _NI_mswin32 ifdef.
It is technically equivalent to __int64, which allows direct maths.
> -re: EVENT_PANEL_SIZING This feature was introduced in CVI 8.1.
My bad. I'm fast to fump onto new features !
> -re: other predefined macros _NI_unix_ is also defined.
>
> -re: SMB file access error Windows file systems have several more
> permissions differences from unix file systems. The ability to modify
> a file is separate from the ability to delete or create a file. When
> cvicc calls gcc to compile the file it is going to delete the old
> object file and then try to write a new file. This could be why
> 'touch'-ing the file succeeds, but compiling it does not.
I gave up trying to share it via SMB from the windows machine. If on the
other hand I share it on NFS from the Linux machine, it works fine. Maybe
worth checking into...
> -re: cvicc and gcc relation cvicc is implemented as a wrapper that
> reads the project file, determines which files to compile, uses gcc to
> compile, determines what things to put in the link, and then used ld
> to do the final link and create the output binary. You can add
> addition link libraries to the cvicc with the -llibname option that
> gets passed to ld. If you want to change the gcc compile options you
> can edit the file /usr/local/natinst/cvi80/bin/compile.ecc This is a
> external compiler support (from Windows) file that was customized for
> linux. The line with COMPFLAGS gets added to the command line that
> compiles each .c file into a .o file The line with LINKFLAGS get added
> to the command line that performs the final link.
Thank you for the details, that may prove very useful for customizing a
final version or
