On Tuesday, 23 October 2012 at 06:35:06 UTC, Jacob Carlborg wrote:
> On 2012-10-22 21:48, Brad Lanam wrote:
> How can you mention bourne shell and portability in the same sentence? I doesn't work on Windows (yes I know about cygwin and mingw). Clang does work on Windows, I just haven't been able to compile DStep for Windows yet due to optlink not cooperating.
>
> Sure, if you're satisfied with Posix then I guess that's fine. But it's not really easy to build cross-platform code with shell script.

I'm sorry, I don't see how that follows.  My scripts work on All variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64, HP-UX, All *BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare, Windows Cygwin.  My 'di' program builds on all of the above with a simple 'make' as it uses my build tool.  And I don't need to install any special tools.  These are just the systems I have access to.

How is that not cross-platform?  How is that not portable?  How is that not easy?

If I had a D compiler on all those platforms, the D version of the 'di' program would build everywhere with just a 'make'.

>> If you need to write code that runs on multiple systems and works with
>> low level system calls (rpc, et.al.), my tool might be a better choice.
>
> Why would that make a difference.

Not all systems are alike.

      static if (_c_args_setmntent == 1)
      {
        f = setmntent (toStringz(DI_MOUNT_FILE));
      } else static if (_c_args_setmntent == 2) {
        f = setmntent (toStringz(DI_MOUNT_FILE), toStringz("r"));
      }

If I understand your tool correctly, you might convert the mount.h or mntent.h file [but how does your program decide which one and even if they exist?].  But then how are you going to change your code to handle the above?  You've got a *lot* of work to do if you want a cross platform tool.

I recommend SWIG+CMAKE.  Or my 'mkconfig' tool.

On 2012-10-23 19:42, Brad Lanam wrote:

> I'm sorry, I don't see how that follows.  My scripts work on All
> variants of Linux (2.4, 2.6), Solaris (2.6 - 11), AIX, Tru64, HP-UX, All
> *BSD, Mac OSX, Haiku, QNX, SCO, Syllable, UnixWare, Windows Cygwin.  My
> 'di' program builds on all of the above with a simple 'make' as it uses
> my build tool.  And I don't need to install any special tools.  These
> are just the systems I have access to.

All of these don't use the same shell. Requiring to install bash would mean you do need to install special tools. Not really special but additional tools. But I would count Cygwin as a special tool for Windows.

> How is that not cross-platform?  How is that not portable?  How is that
> not easy?
>
> If I had a D compiler on all those platforms, the D version of the 'di'
> program would build everywhere with just a 'make'.
>
>>> If you need to write code that runs on multiple systems and works with
>>> low level system calls (rpc, et.al.), my tool might be a better choice.
>>
>> Why would that make a difference.
>
> Not all systems are alike.
>
>        static if (_c_args_setmntent == 1)
>        {
>          f = setmntent (toStringz(DI_MOUNT_FILE));
>        } else static if (_c_args_setmntent == 2) {
>          f = setmntent (toStringz(DI_MOUNT_FILE), toStringz("r"));
>        }
>
> If I understand your tool correctly, you might convert the mount.h or
> mntent.h file [but how does your program decide which one and even if
> they exist?].  But then how are you going to change your code to handle
> the above?  You've got a *lot* of work to do if you want a cross
> platform tool.
>
> I recommend SWIG+CMAKE.  Or my 'mkconfig' tool.

Well then, how does your tool work?

-- 
/Jacob Carlborg

On Tuesday, 23 October 2012 at 19:10:29 UTC, Jacob Carlborg wrote:
> On 2012-10-23 19:42, Brad Lanam wrote:
> All of these don't use the same shell. Requiring to install bash would mean you do need to install special tools. Not really special but additional tools. But I would count Cygwin as a special tool for Windows.

Oh, maybe were you thinking that bash is the bourne shell?  It's the
bourne-again shell, a rewrite of the bourne shell.  Solaris sh is probably the closest to the original bourne shell.

My tool runs with any bourne shell compatible shell.  It works
with bash2, bash3, bash4, ksh, ksh88, ksh93, Solaris sh, Tru64 sh,
ash, dash, mksh, pdksh. HP-UX sh.

>>>> If you need to write code that runs on multiple systems and works with
>>>> low level system calls (rpc, et.al.), my tool might be a better choice.
>>>
>>> Why would that make a difference.
>>
>> Not all systems are alike.
>>
>>       static if (_c_args_setmntent == 1)
>>       {
>>         f = setmntent (toStringz(DI_MOUNT_FILE));
>>       } else static if (_c_args_setmntent == 2) {
>>         f = setmntent (toStringz(DI_MOUNT_FILE), toStringz("r"));
>>       }
>>
>> If I understand your tool correctly, you might convert the mount.h or
>> mntent.h file [but how does your program decide which one and even if
>> they exist?].  But then how are you going to change your code to handle
>> the above?  You've got a *lot* of work to do if you want a cross
>> platform tool.
>>
>> I recommend SWIG+CMAKE.  Or my 'mkconfig' tool.
>
> Well then, how does your tool work?

You put directives in the "interface file" (to use the SWIG term) to test which capabilities the system has.  It creates an output file (.sh, .c, .d). Depending on those capabilities, the code can use #if or static if statements to provide code that works for the system you are building on.

In the case of the C/D language interface, the directives will extract typedefs, structures, C function declarations, macros, #defines.

On 2012-10-23 21:43, Brad Lanam wrote:

> Oh, maybe were you thinking that bash is the bourne shell?  It's the
> bourne-again shell, a rewrite of the bourne shell.  Solaris sh is
> probably the closest to the original bourne shell.

I thought I said bash somewhere, but perhaps you didn't.

> My tool runs with any bourne shell compatible shell.  It works
> with bash2, bash3, bash4, ksh, ksh88, ksh93, Solaris sh, Tru64 sh,
> ash, dash, mksh, pdksh. HP-UX sh.

I see.

> You put directives in the "interface file" (to use the SWIG term) to
> test which capabilities the system has.  It creates an output file (.sh,
> .c, .d). Depending on those capabilities, the code can use #if or static
> if statements to provide code that works for the system you are building
> on.
>
> In the case of the C/D language interface, the directives will extract
> typedefs, structures, C function declarations, macros, #defines.

Ok, I see.

-- 
/Jacob Carlborg