Hi,

I just want to know why smstools3 do not use some building system like autotools etc? I would be much easier for users to just perform a couple of well-known steps to have a best build for their system.

p.s. I have not found a forum for developers, so asking here. Let me know if there is some better place for such questions.

Vitaly

unterwulf wrote

I just want to know why smstools3 do not use some building system like autotools etc? I would be much easier for users to just perform a couple of well-known steps to have a best build for their system.

Building system has never been required, as this software compiles on (almost) any Unix style systems, including routers and some embedded devices. Currently I do now know about any portability issues, which could be automatically solved by Autotools (other than "-D SOLARIS"). Of course, Autotools could change some settings in the src/Makefile, but some options should then be handled, like number of modems. However, there are no too many lines to change, and with simple instructions this has not been a problem. In the past I quickly checked Autotools, but it seemed like a too big job to implement it.

unterwulf wrote

p.s. I have not found a forum for developers, so asking here. Let me know if there is some better place for such questions.

"Help and support" is ok, and "Feature requests" is ok too, as this topic is "discuss about features which could be enhanced". I moved this topic to "Feature requests", because in "Help and support" topics are closed more frequently.

keke wrote

Currently I do now know about any portability issues, which could be automatically solved by Autotools (other than "-D SOLARIS").

Actually there are two more:
- Automake can detect whether iconv() is available and included in libc/installed as a separate library.
- The configuration parameter os_cygwin doesn't need to be configurable in runtime, it should be determined at compilation time.

keke wrote

In the past I quickly checked Autotools, but it seemed like a too big job to implement it.

It is a false impression :-) Migration to autotools is not a big deal. I can prepare the patch if you are interested in it.

One more portability issue: [solved] Compile on OpenBSD 4.5

unterwulf wrote

keke wrote

Currently I do now know about any portability issues, which could be automatically solved by Autotools (other than "-D SOLARIS").

Actually there are two more:
- Automake can detect whether iconv() is available and included in libc/installed as a separate library.
- The configuration parameter os_cygwin doesn't need to be configurable in runtime, it should be determined at compilation time.

Yes, there are couple of lines to adjust in the Makefile, but in the usual cases no adjusting is required.

In some cases ICONV is not used, even when it's available, meaning that option is required for this. The same applies to INET_SOCKET. A definition USE_LINUX_PS_TRICK is removed in the next version, so it does not require any option.

Previously os_cygwin was in the Makefile, but it was moved to the configuration. The same settings applies to MinGW too.

unterwulf wrote

keke wrote

In the past I quickly checked Autotools, but it seemed like a too big job to implement it.

It is a false impression :-) Migration to autotools is not a big deal. I can prepare the patch if you are interested in it.

False or not , but it was my impression at that time. Simple migration, like described for example at http://markuskimius.wikidot.com/programming:tut:autotools, was not enough.

If you can prepare the patch, I'm of course interested to see it.

unterwulf wrote

One more portability issue: [solved] Compile on OpenBSD 4.5

Do you mean that Makefile should be compatible with both GNU make and OpenBSD's make?

keke wrote

In some cases ICONV is not used, even when it's available, meaning that option is required for this. The same applies to INET_SOCKET. A definition USE_LINUX_PS_TRICK is removed in the next version, so it does not require any option.

These cases will be covered by ./configure --without-iconv --disable-inet-socket.

keke wrote

Previously os_cygwin was in the Makefile, but it was moved to the configuration. The same settings applies to MinGW too.

This still doesn't mean that it needs to be configurable in runtime. I can imagine only two situations when this parameter might need to be configurable in runtime:
1. It may need to be disabled when running under Cygwin.
2. The same binary can be used on several platforms that require different behavior.

Does any of two make sense in real life?

I am not familiar with MinGW, but my guess is that it still require that binary should be built for it as a target platform, and autoconf seems to be able to recognize mingw as well as cygwin.

keke wrote

Simple migration, like described for example at http://markuskimius.wikidot.com/programming:tut:autotools, was not enough.

If you can prepare the patch, I'm of course interested to see it.

OK.

keke wrote

Do you mean that Makefile should be compatible with both GNU make and OpenBSD's make?

Actually, no ;-) I mean that, despite the user had gmake, the building process didn't advice him to use it and he had to spent time to find it out himself.

OMG! I've just realized that I forgot to mention the main reason that forced me to modify smstools3 build process :-) Current implementation has no means to install the software into a staging area (see Staged-Installs for details), although this feature is very helpful for building packages.

Hi Keke,

The patchset is ready. Please find it at [1].
An autotools generated distribution is also available at [2]. It probably worth to be looked at firstly, as it doesn't require any additional tools to be installed.

Brief description of the new features:
- staging area installation support
- iconv/libiconv autodetection (can be explicitly enabled/disabled)
- inet socket availability autodetection (inet socket will be automatically disabled if the system doesn't support it)
- Cygwin autodetection (instead of the os_cygwin parameter)
- distribution autogeneration (make dist)
- more accurate handling of the installation prefix
- no need to edit Makefile, all parameters are configurable via the ./configure options.

Using this distribution I was able to build the software on Linux, Cygwin, SunOS 5.8, SunOS 5.9, OpenBSD and FreeBSD. I didn't tested any functionality of the software, only the building process itself (+compilation options etc).

BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.

I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?

[1] https://github.com/unterwulf/smstools3-uw/commits/
[2] https://github.com/downloads/unterwulf/smstools3-uw/smstools3-3.1.14-uw.tar.gz

Thanks for the patchset.

Just for your information, I'm little bit busy nowadays, and will continue with this topic later when I have enough time.

In the meanwhile:

unterwulf wrote

BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.

What was that bug?

unterwulf wrote

I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?

Yes, it really is supported, just like most other Unix-style platforms.

keke wrote

unterwulf wrote

BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.

What was that bug?

The issue was that Solaris' headers do not define the NAME_MAX macro.

# gmake cd src && gmake - gmake[1]: Entering directory `/home/vs/src/smstools3/src' cc -D NUMBER_OF_MODEMS=64 -D NOSTATS -W -Wall -D_FILE_OFFSET_BITS=64 -c -o extras.o extras.c extras.c: In function `getfile': extras.c:522: error: `NAME_MAX' undeclared (first use in this function) extras.c:522: error: (Each undeclared identifier is reported only once extras.c:522: error: for each function it appears in.) gmake[1]: *** [extras.o] Error 1 gmake[1]: Leaving directory `/home/vs/src/smstools3/src/smstools3/src' gmake: *** [compile] Error 2

The definition of NAME_MAX is commented out in the Solaris' limits.h with
the following note:

/* * POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the * related text states: * * A definition of one of the values from Table 2-5 shall be omitted from the * <limits.h> on specific implementations where the corresponding value is * equal to or greater than the stated minimum, but where the value can vary * depending on the file to which it is applied. The actual value supported for * a specific pathname shall be provided by the pathconf() (5.7.1) function. * * This is clear that any machine supporting multiple file system types * and/or a network can not include this define, regardless of protection * by the _POSIX_SOURCE and _POSIX_C_SOURCE flags. * * #define NAME_MAX 14 */



I verified this on the following systems ('uname -a' output):
* SunOS hostname 5.10 Generic_142900-06 sun4u sparc SUNW,Sun-Fire-V890
* SunOS hostname 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-480R

keke wrote

unterwulf wrote

I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?

Yes, it really is supported, just like most other Unix-style platforms.

As far as I can see MinGW does not even support the fork() call [1], so I wonder how can smsd be built under MinGW. Have you really been able to compile it under MinGW?

[1] http://www.mingw.org/node/21

unterwulf wrote

keke wrote

unterwulf wrote

BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.

What was that bug?

The issue was that Solaris' headers do not define the NAME_MAX macro.

Okay, thanks. Fixed 256 will be a good size for that buffer, without any definitions, as in most systems the NAME_MAX is 255.

unterwulf wrote

keke wrote

unterwulf wrote

I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?

Yes, it really is supported, just like most other Unix-style platforms.

As far as I can see MinGW does not even support the fork() call [1], so I wonder how can smsd be built under MinGW. Have you really been able to compile it under MinGW?

[1] http://www.mingw.org/node/21

I personally do not even have MinGW installed, so I have not tried to compile smsd under it. Some people have mentioned MinGW, perhaps together with Cygwin, or alone, I do not know for sure, but I have then assumed that whatever the system is, it was used successfully. Perhaps there was some reimplementations done, but I do not know about them, and I do not intend to investigate them.

What I mean, and what is the most important thing, is that the new compiling/installation system should work without troubles in any possible environments where current makefiles do the job. Including environments whose existence I do not even know, or could test them.