SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Tue Jun 25, 2024 15:05
SMSTools3 Community » Feature requests Bottom

Why not to use autotools?

Login and Post Reply

Page:  1

Author Post
Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
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

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
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.

Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
Topic owner
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.


« Last edit by unterwulf on Sun May 01, 2011 22:14, 160 months ago. »
Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
Topic owner
One more portability issue: [solved] Compile on OpenBSD 4.5

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
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?

Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
Topic owner
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.

Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
Topic owner
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


« Last edit by unterwulf on Mon May 09, 2011 08:26, 159 months ago. »
Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
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.

Member
Registered:
Apr 2011
Location: Kupchino, Russian Federation
Topic owner
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.



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





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

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
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.

Login and Post Reply

Page:  1

SMSTools3 Community » Feature requests Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.