Make the system platform independent

[wijnen]

As noticed in #208 I would like to allow projects using this Makefile to be platform independent. This requires some support from this code, but most work needs to be done by the packagers. It's not a lot of work, just an agreement on how to do things.

It would be nice if the include statement would somehow reference "the system include path", but I don't think Make defines such a thing. This means that either Arduino.mk must be linked to the project's source directory, or the full path (on my system, /usr/share/arduino/Arduino.mk) needs to be specified. The former leads to code duplication and the latter leads to a platform dependent build system.

The usual way to fix such a problem is by adding a configure script, which looks at your platform specifics. This does not mean autoconf is required; that's just a very complicated way to create a configure script. We only need a simple script, so it can be written by hand.

My aim is to make sure that all code in a project is platform independent. This means that anything platform-specific must be defined by things on the system, and that those things must have the same interface across all systems.

I argue above that a configure script would be useful for adding a link to Arduino.mk. But where is that file located? And what is the command for adding a link? These are platform specific things, so they must be wrapped in a script that can be called from configure (and in fact, that's the only thing configure needs to do, I think).

The different versions of that script could be shipped with this project, so that every packager (or person who manually installs it) can pick the one for their system and use that.

To make things clear: this is what such a script could look like on Debian:

link_arduino_makefile:

#!/bin/sh
ln -s /usr/share/arduino/Arduino.mk .

The power is not in the complexity of the code, but in the fact that different platforms each provide their own version of this script and install it on their system path, so that a project that uses a configure script like this:

configure:

#!/bin/sh
link_arduino_makefile

This will make sure that "./configure; make; make upload" will work on all platforms, very much like people expect when using Make.

[sudar]

I agree that we should make the makefile as platform independent as possible. But at the same time I don't want to make the config scripts too complex and make it very difficult for package maintainers.

One other approach that we can use, instead of linking the .mk file is to set the ARDMK_DIR varaible and then just do the following in the user makefile

include $ARDMK_DIR/arduino.mk

In fact I do this both in my mac and Ubuntu desktop where I use this makefile.

[sej7278]

yes i'm not keen on having a configure script just to install a makefile lol, that's really going over the top. in fact we had some complaints from debian users at one point that we'd made it too complicated, so we removed the git-vs-pkg differences so now it will work by just using BOARD_TAG and the include line.

i don't think anyone else packages arduino-mk, debian/ubuntu are already covered, fedora we have a specfile for and archlinux also have a package, they all use the same standardised directories for docs/manpages/binaries.

[wijnen]

On Mon, May 26, 2014 at 10:04:27PM -0700, Sudar wrote:

I agree that we should make the makefile as platform independent as possible. But at the same time I don't want to make the config scripts too complex and make it very difficult for package maintainers.

Very much agreed. No configure script would certainly be better.

include $ARDMK_DIR/arduino.mk

Yes, that's a better solution indeed.

On Tue, May 27, 2014 at 02:51:02AM -0700, sej7278 wrote:

yes i'm not keen on having a configure script just to install a makefile lol, that's really going over the top. in fact we had some complaints from debian users at one point that we'd made it too complicated, so we removed the git-vs-pkg differences so now it will work by just using BOARD_TAG and the include line.

I agree, the simpler the project Makefile can be, the better. Things are looking very good already in that respect.

i don't think anyone else packages arduino-mk, debian/ubuntu are already covered, fedora we have a specfile for and archlinux also have a package, they all use the same standardised directories for docs/manpages/binaries.

But even without a package, people may want to use the system on Windows, or on a machine where they don't have root access. Using an absolute path in the project Makefile causes problems for those cases. But with an environment variable, those problems should be solved. :-)

The main thing that needs to be done here, is document that adding this environment variable is the proper installation procedure. Then both packagers and people installing it manually will know what to do, and projects will work everywhere.

Thanks, Bas

[sudar]

The main thing that needs to be done here, is document that adding this environment variable is the proper installation procedure.

Agreed. Right now it is documented only in https://github.com/sudar/Arduino-Makefile/blob/master/arduino-mk-vars.md. We need to add a note about it in README file as well.

Do you think we should add about it anywhere else?

[sej7278]

yes we spent quite a while sorting out $ARDMK_DIR during the git-vs-pkg issue.

it would be good to properly document it i guess. however its pretty automatic now - it figures it out based on where you've included Arduino.mk from in your Makefile, you don't really need to override it.

i've got a feeling @wijnen is trying to sort out a problem that doesn't exist in the latest code, do we have an example case?

[wijnen]

@sej7278 I'm using Debian myself. I want my project to contain a Makefile that looks like:

BOARD_TAG = uno
include $ARDUINO_MAKEFILE

This currently doesn't work on my system (or anywhere else, as far as I know). So I would need to tell my users (I'm talking about people who want to change and compile my code) that they have to define this variable to where they have the Makefile installed.

Defining a variable for myself is not a problem. Telling my users to do so isn't nice. Especially if they install the Makefile from a package; the package should make sure that it just works. But if everyone uses different conventions for what variable names to use, the package can't do it right. So a standard way needs to be defined, which can then be used by everyone.

@sudar I think the README should be good enough. My main point is that it should say that the above example is how people should use the Makefile, and on installation of the Makefile they (including packagers) therefore need to make sure that this variable is set to the install location.

ARDUINO_MAKEFILE sounds better to me than ARDMK_DIR. And I'd prefer to reference the Makefile, not the dir; as @sej7278 wrote it can figure the dir out by itself and it would avoid people on case insensitive filesystems to ignore the case and create Makefiles that don't work on other systems.

But I don't care much about its name. The main point is that it is specified.

[sej7278]

@wijnen i can't see how you could do what you want. somewhere your user is going to have to define $ARDMK_DIR or whatever, either in their environment or in the include line. its not rocket science, there's only so much dumbing down you can do and i'd argue that a user who is programming microcontrollers with a makefile can figure out how to fill in an include line.

the only way you could achieve it that i can think of is if you make the makefile into a binary that you could call from your $PATH, which we definitely don't want to do; or you could make some sort of installer yourself so you know where the include line should point (maybe a registry variable) with e.g. innosetup on windows. for linux you already know where the makefile will be.

[wijnen]

@sej7278 I think you're misunderstanding me. What I want: distribute my projects to people who aren't programmers, before it is really released (in other words, before I distribute it as compiled files). Similar to how they can run "./configure; make; make install" for software projects, I want them to run "make; make upload" for these Arduino projects. That should "just work" without any changes to my code on their part.

For this, they will of course need to install all the build dependencies first. This Makefile is one of those build dependencies. Installing it should consist of:

1. Put the files in some location.
2. Define the environment variable (in a persistent way).

My point is, that I don't want my users to have different versions of that last step depending on if they are building my project or yours. So I want the variable to have a standard name, that everyone uses in their project Makefiles. Then on Debian, the variable can be installed by the package, and "installing this build dependency" means installing a package with no further action.

Without defining that this variable should be used, it is impossible for me to write a project Makefile that just works everywhere. I'd always need to tell people "after installing the Makefile, you need to set up this environment variable" or "you need to edit my code". Both of those options are undesirable. So they should be avoided, which luckily is quite easy.

[ladislas]

@wijnen what kind of variables are you talking about?

if you want everything to compile relative to your project directory, why not use the PROJECT_DIR variable like in the Makefile Example and set it using a shell command like pwd?

Or am I also misunderstanding something? :)

[wijnen]

@tinyladi I'm talking about ARDUINO_MAKEFILE, defined when installing the Makefile, which points to the install location. It makes sure that "include $ARDUINO_MAKEFILE" will work.

I can tell my users to do this, but I want this to be part of the installation instructions for this Makefile, so that my users don't need to do anything extra when building my project (because they, or their package managers, have already done it when installing the Makefile).

[wijnen]

To be more clear: this is what I want to get rid of:

### This is an example Makefile and it MUST be configured to suit your needs.

[ladislas]

why don't you just include the Makefile as a submodule of your project then?

that's what I do for mine and it works pretty well for everyone who ever wanted to build my code on their machine. Tried on OS X and Linux with no problems at all.

[ladislas]

it has to be configured because I use some specific software such as avr-gcc-4.8 and the location is different from one user to another.

If you want to use the Arudino IDE binaries, you also have to make sure that the user has installed the IDE first.

[wijnen]

Yes, I noticed that my comment wasn't as clear as I wanted.

it has to be configured because I use some specific software such as avr-gcc-4.8 and the location is different from one user to another.

Exactly. But it is not specifc to your project; it is specific to their system. So this information should be defined by their system. Because if you define it in your project, users with different systems will need to edit your project files.

You are including a copy of the Makefile in your project tree. That is code duplication, which causes problems (you don't benefit from updates, including security updates, unless you release a new version of your package whenever a new version of the Makefile is released). I want to install this Makefile systemwide. As part of this install these (system-dependent, but project-independent) variables need to be set:

• ARDMK_DIR
• ARDUINO_DIR
• AVR_TOOLS_DIR
• AVRDUDE
• MONITOR_PORT

They should NOT be part of my project Makefile. Because if they are, then my users need to use edit the Makefile when they're running on a Mac, or on Windows. I want the full preparation to consist of "install that Makefile on your system and download my source". I want to avoid "you need to edit this file before you can compile it".

Now that I write this list here, I notice that ARDMK_DIR is already in there. So it's possible to use "include $(ARDMK_DIR)/Arduino.mk" instead of "include $(ARDUINO_MAKEFILE)". I would still prefer the latter though; ARDMK_DIR wouldn't need to be defined then, because it can be deduced from the include location (or from ARDUINO_MAKEFILE).

As part of saying "these should be defined in your system, not in your project", the example Makefile should of course not define them.

It should also not contain any absolute paths for the same reason. Why is it useful to define PROJECT_DIR? Can't you just expect people to run make in the directory where the Makefile is, and use pwd?

I want a simple Makefile to be no more than:

BOARD_TAG=mega2560
include $(ARDUINO_MAKEFILE)

Extra features like code consistency checks are possible, but this should be enough for the "make" and "make upload" targets. And if you want to support multiple boards, you'll even remove the first line and tell users to use "make BOARD_TAG=their_board".

[sej7278]

i'd say like @tinyladi said, have a local install of Arduino.mk (etc.) as part of your application so you can just include from the CWD, or put some logic in your Makefile to figure out where Arduino.mk is installed

i just don't see how you can do "include $ARDUINO_MAKEFILE" without defining it somehow. its not a binary so a symlink is not really achieving anything, you can't do "which Arduino.mk" or "whereis Arduino.mk"

[wijnen]

i just don't see how you can do "include $ARDUINO_MAKEFILE" without defining it somehow.

Of course it should be defined. That's what I'm asking for: please make "define ARDUINO_MAKEFILE as a persistent environment variable" part of the installation procedure of this Makefile. (Along with the list I mentioned above, by the way.)

I think I see the misunderstanding/disagreement: I consider code duplication to be evil, and want to avoid a local copy of Arduino.mk as part of my project at all costs. You don't seem to consider it a problem.

[ladislas]

I think you're trying to reinvent the wheel...

The thing is, when you want to use a makefile, you prepare yourself for some hardcore sh*t and that's what fun about it. Using the make file make it already so much easier than using the Arduino IDE, I don't think that's a problem to set a few variables and that people won't use your project just because they have to modify a small line of code...

And think about it, you want global variables to be defined so that I can compile your project. But I have to be aware in the beginning that I need to install the Makefile package. I think it is even more cumbersome to ask people to install something else globally rather than package everything for your app to compile the right way and to be able to just rm -rf everything when I'm bored...

Think about it as node modules. You're never asked to npm install **-g** anAwesomeModule to be able to run an application. you juste call npm install and it installs everything locally with the versions you specified.

[sej7278]

but how do you make it an environment variable?! you'd then have to get your user's to change their profiles which is even more confusing.

you can't do it from arduino-mk as its a chicken and egg situation.

[wijnen]

The thing is, when you want to use a makefile, you prepare yourself for some hardcore sh*t and that's what fun about it.

Yes, I like it, and I don't have a problem messing with Makefiles. But I'm writing firmware for a 3-D printer. My users want a working printer, there's already quite a bit of technical expertise required for building one. "Learning how a Makefile works" is not currently part of it, and I'd like to keep it that way (they can tweak more if they do know this, but things will still work if they don't).

I want to tell Debian users: install the arduino-mk package and you're good to go. Windows users don't have a package manager; that's their problem. They probably don't want to compile anything anyway. Those that do will know how to do it. My main advice for them is to use a different system.

I'm not saying it must be installed globally, just that that is the way I would suggest to do it: there should be a package which does this, they know how to install packages on their system. It's by far the easiest way to do it. Note that I'm talking about people who don't know anything about Arduino, and not all of them will want to learn about it. I want those people to be able to use my project, too.

but how do you make it an environment variable?!

That all depends on your system. Which is exactly why my project Makefile cannot do it. It must be done as part of installing the Arduino.mk (be it globally or locally).

you'd then have to get your user's to change their profiles which is even more confusing.

That's all up to them. My recommended way of installing arduino-mk would be with a package manager. The package is system-dependent, so it can contain some magic to define global environment variables (for example, in /etc/profile.d/arduino-mk). The user just installs the package and it works (after logging out and back in, unfortunately, but I don't think it gets better than that).

It doesn't mean other methods don't work: if a user downloads the files manually and puts them in ~/arduino-mk/, they can set up their own variables. This can be part of their user profile, or they can make a script to do it which they must source before running make. For people who decide that they don't want to use a package manager, I think this is not a problem. The other alternative is to make them edit the project's Makefile, which is just as hard. But then the package manager approach doesn't work. So there are only downsides to that approach.

[ladislas]

hmm...

I'm trying to compare:

• git clone myProject
• download and install the Arduino IDE or package
• install the makefile package
• make to compile

to:

• git clone MyProject && git submodule init && git submodule update
• download the IDE
• make to compile

I really think the magic has to be on your side, make a shell script or something and use the makefile as a submodule.

By doing so you're sure it works as is!

[wijnen]

I'm expecting people to download the zipfile rather than checking out the repository. The submodule approach won't work then, I think. Plus I want to make my code a Debian package itself. I can declare other packages as (build-)dependencies. If I need to add a script, then I'm including code in my package which is really part of the dependency (arduino-mk).

The whole point of a packaging system is that things work together seamlessly. A script in my package which fixes the inability of another package to be found would do the job, sure. But it's ugly. And given that it's unnecessary, I'd much rather see this fixed at the source.

Note that people may want to compile more than one project which uses this Makefile. With my approach, they only need to install the package once. For every new program, they only need:

• download the project
• make

Also, if any problems are found and fixed in arduino-mk, they will automatically get those changes the next time they update their system. If they have a copy of it for every project they check out, none of these copies will be updated.

[wijnen]

Note also that your first recipe is needlessly complex: "install the makefile package" will automatically pull in everything it needs, so you don't need to install the Arduino package manually. It really is:

• install arduino-mk package
• download the project
• make

and the first step only needs to be done once. I don't see how it can get any easier.

[ladislas]

Well I don't know then...

Maybe, try to do it by yourself, make it work and if it's as easy as it seems, it will be incorporated.

[wijnen]

Make the Debian package you mean? Sure, I can do that. I'll send it here when I have it done. It may take a while because I'm rather busy and I want to test it well.

[ladislas]

yep :)

[sej7278]

yup, i'm quite lost i'm afraid. might be best if you send sudar a pull request, and we can look at tweaks to the deb package if needed.

i can see that you could add something in /etc/profile.d/ but i'm not keen on a global environment variable. possibly create a dotfile in the user's $HOME when they first run your program? in fact you could do that without changing anything here....

p.s. i'm sure you know, but you don't need the IDE to use the arduino-mk, you can just install arduino-core and python-serial

[sudar]

Just woke up and I seemed to have missed lot of action during my night time ;)

@wijnen,

I see your point that you don't want your users to make any changes and should just be able to do make or make upload. And I also agree with you on the code duplication part and the reason why you don't want to use git submodule.

But the project makefile needs to know where the parent makefile is and so you are suggesting to automatically set the environmental variable ARDMK_DIR where the arduino-mk package is installed. I am not fully convinced that the package installer should do it, but even if we agree that the package installer to do this, there are a few problems.

Generally when a package is installed the binaries are automatically added to the path by symlinking to a directory that will in the path like /usr/bin or /usr/local/bin`. We do this for the reset script since it is a binary. But the makefile is not a binary file and as @sej7278 said we can't symlink them.

So the next option is to automatically set the ARDMK_DIR environmental variable. The usual way to set the ARDMK_DIR is to add it to ~/.bashrc or ~/.profile. I am not an expert in package management so I may be wrong here, but most packages that I installed which needs to modify the PATH or CLASSPATH variable suggested the user to manually place it and not automatically append it to their ~/.bashrc or ~/.profile file. So I am not sure if the package should append the variable when it is installed. But if possible, we can output a message that says that if the users wishes he can set the ARDMK_DIR when the package is installed. @sej7278 Is there a provision to do something like this while creating debian packages? Meanwhile, @wijnen if you find a way to do it, then send us a pull request.

Alternatively, you could also add to your documentation that users should set the ARDMK_DIR variable and in your project makefile just include the following lines.

BOARD_TAG=uno
include $ARDMK_DIR/arduino.mk

Even I feel that asking a unix/linux user to set an environmental variable is not too much of an ask. But again your user base may be different.

[wijnen]

@sudar I want to avoid "after you installed this package, you need to do X or else you can't actually use it". The point of a package management system is that it will do whatever is required to make use of the program. So telling the user that they need to set an environment variable, while not being complicated, is a step I really want to avoid.

However, I agree with you that adding globals to the environment is non-ideal, and the fact that the user will need to log out and back in to make it take effect isn't nice either. But you gave me a different idea: it would be possible to add an executable to the path which will report the location of the Makefile (and any other parts, so the Makefile can itself use it to get defaults for all the other variables as well), similar to how pkg-config is used. Then a project Makefile would look like:

BOARD_TAG=uno
include $(shell arduino-find-makefile)

which is simple enough. The arduino-find-makefile script can return the absolute path of the makefile if called with no arguments, and other configuration (monitor_port, ardmk_dir, etc) when using that name as an argument. I like this better than a global variable. Before I write all the code, I'd like to know if you like it, too. :-)

[wijnen]

To be a bit more clear on what I want to do: I want to put arduino-find-makefile.in in the source and parse it with autoconf just like you would a pkgconfig file. Then use automake to install it to wherever the user requests it to be (with configure's --prefix option). So I'd use autoconf+automake to install Arduino.mk and all the corresponding files, including arduino-find-makefile. For Debian, this is done at package build time. Then when installing the package, everything is in the proper location and things will just work. People who use the Makefile without a package will need to run ./configure; make; make install. Since they'll know what a Makefile is, this shouldn't be a problem for them.

[sej7278]

@wijnen i'm not keen on putting a configure script and autoconf/automake anywhere near the arduino-mk debian package, its complete overkill.

debian has standards for where it installs stuff, and we're compliant to that - its a standard location on all linux platforms that have an arduino-mk package, so not sure why you need to define where it installs to, when you already know.

you could use apt to find the location of Arduino.mk for you:

$ dpkg -S Arduino.mk
arduino-mk: /usr/share/arduino/Arduino.mk

$ dpkg -L arduino-mk | grep Arduino.mk
/usr/share/arduino/Arduino.mk

$ apt-file search Arduino.mk
arduino-mk: /usr/share/arduino/Arduino.mk

but its always going to return /usr/share/arduino/Arduino.mk as that's where the debian package puts it!

i still think you're worrying about a problem that doesn't exist - unless you're using git, which you're not, and if you were you just script a checkout so you know where it goes.

[sudar]

@wijnen Will @sej7278 solution work for you?

If we can solve it simply, then I would prefer that, rather than introducing dependency on other tools that we don't need.

[wijnen]

@sej7278 No, you're misunderstanding my problem. I'll try to explain it with an example.

I'm writing code and want to use the Makefile to compile it. I give build instructions to my users:

• install the arduino-mk package
• run make

I want these build instructions to work for everyone, independent of which OS they're using. While on my system the Makefile will be in /usr/share/arduino, on Windows and Mac that directory doesn't even exist. And people who install it manually (in /usr/local or ~/.local, for example) have yet another path. I want my build instructions to work for all of them.

Things I want to avoid:

• Copying Arduino.mk into my source tree.
• "as part of building my software, you need to edit this file".
• "as part of building my software, you need to set this variable".
• "as part of using Arduino.mk, you must add multiple lines of code to your Makefile so that it can find it, wherever it is installed"

So the problem is not that I don't know where my Makefile is; the problem is that I want to tell random people where their Makefile is, and it isn't the same for everyone. (Or more correct: I want my project Makefile to find their Arduino.mk, regardless of where it is installed.) This is why I want to install an executable to the path as part of installing the Makefile. This executable can then inform the caller about the location of the Makefile (and if there's an executable anyway, it can inform about other system specifics as well).

@sudar It's well possible to do this without autotools as well; it just means there's a custom install script (I'd still use a Makefile, actually) with custom arguments. I think people will like autotools because they know the interface, but since we're only installing a few non-compiled files, it's a bit like hitting a fly with a sledge hammer. ;-) Since you don't like the dependency, I can also write the custom install Makefile manually. However, I'm not familiar with Windows or Mac; I think autotools would be able to install things in the correct paths for those systems, but I'm not.

Note that the autotools dependency would be on Arduino.mk, not on the actual projects using it. So on Debian, arduino-mk would need a Build-Depends on automake; installing the binary package does not require autotools, and the actual projects just require the package to be installed and have nothing to do with autotools either.

[peplin]

Things I want to avoid: Copying Arduino.mk into my source tree. "as part of building my software, you need to edit this file". "as part of building my software, you need to set this variable". "as part of using Arduino.mk, you must add multiple lines of code to your Makefile so that it can find it, wherever it is installed"

Chiming in with another dev's experience with this, I distribute another project that uses the Arduino-Makefile and I don't need the users to do anything like this. I include the Arduino-Makefile repository in my project as a git submodule, so the only installation step is to run git submodule update --init, which I automate as a part of the normal dependency installation script. With that, my Makefile manually sets the ARDUINO_MAKEFILE_HOME and includes it: https://github.com/openxc/vi-firmware/blob/master/src/platform/pic32/pic32.mk#L104

[wijnen]

@peplin Thanks for your message; these sort of things help me explain what I want, because it seems I have trouble with that. :-)

I think this Makefile should be part of the build system, just like the compiler is. I don't want to tell my users to copy this Makefile into my source tree, just like I don't want to tell them to copy the compiler. Instead, I tell them to install the compiler (and this Makefile) on their system path and I call it in a way that just works; the "install" part (of the compiler) makes sure of that.

Does that make my goal more clear?

[peplin]

I think your goal is clear, but all of the possible solutions discussed so far are a headache for the package maintainers, which is why I think you're meeting some resistance. You may want to re-consider if it's such a burden to have Arduino-Makefile in your source - consider that even Android Studio ships with a copy of its build tool (Gradle) in each new Android project, since that's way easier to keep stable across all users than dealing with a million different system configurations and install paths.

[sudar]

I think your goal is clear, but all of the possible solutions discussed so far are a headache for the package maintainers, which is why I think you're meeting some resistance

Exactly :)

@wijnen,

"as part of building my software, you need to set this variable".

I know you want to avoid doing this, but given your usecase, I would recommend you to do it.

[sej7278]

yup, a dotfile is the easiest way to do it, and most portable with no code duplication. tweaking the debian package or using autoconf isn't going to help mac/windows/git users, its just more dependencies.

[wijnen]

I think your goal is clear

Well, because of comments like this I don't agree:

not sure why you need to define where it installs to, when you already know.

This tells me how I, as a project maintainer, can make sure that I can compile my own project. That is not the problem I'm trying to solve.

What I want is to release my project. Have other people compile it. And I want it to be easy for them. With libraries, this same problem has already been solved, and autoconf, automake and pkg-config have been created for this solution (and there are alternatives too, such as cmake with pkg-config). In our case, pkg-config is probably not appropriate, but I think autotools are useful.

With libraries, (most) people have found that including a copy of the code in your source is a very bad idea. It's acceptable as long as your library is experimental and the only people using it are people working on it. It isn't acceptable for a release.

"as part of building my software, you need to set this variable".

I know you want to avoid doing this, but given your usecase, I would recommend you to do it.

But this is the sort of problem that needs to be automated! Computers are good at this. Why should my users need to go through the trouble of manually setting an environment variable, when it can be solved automatically?

I, in my project, cannot tell users where their arduino-mk is installed, because I don't know. But the arduino-mk installation procedure can make sure that I have a way to find out. When I have that, I don't need to ask my users anything.

Finally some words about autoconf. I'm not hung up on using it. If you're really opposed to autoconf, this can be done without it. (But it won't work as well, because autoconf solves a real problem.) What I want is an executable which should be installed such that a shell spawned from a Makefile can find it, which reports the system details. That, and a change in the documentation which says that for a released project (as opposed to an experimental personal project), the recommended way to use arduino-mk is by calling that executable to find the Makefile.

[sudar]

I think your goal is clear

Well, because of comments like this I don't agree:

@wijnen All along, I understand your usecase and I am not denying the fact that it is a valid usecase. But every solution will have a compromise and I feel that on the whole we are compromising less if you choose to add a documentation to your installation guide asking the users to set the environment variable instead of using either autoconf or an executable.

"as part of building my software, you need to set this variable".

I know you want to avoid doing this, but given your usecase, I would recommend you to do it.

But this is the sort of problem that needs to be automated! Computers are good at this. Why should my users need to go through the trouble of manually setting an environment variable, when it can be solved automatically?

Again I am not denying that computers are good at it, but as @sej7278 pointed out we have lot of different ways by which users install this makefile. Not all users install the makefile using the package or all of them using only debian/ubuntu.

From the package maintenance perspective we feel that this is definitely an overkill and also your usecase is not a common usecase.

What I want is an executable which should be installed such that a shell spawned from a Makefile can find it, which reports the system details.

This solution is not portable. Because currently we have users from debian/ubuntu, mac and windows. Making the executable portable across all these platforms and continuing to maintain it is going to be a major headache and I don't think either me or @sej7278 or any of the package maintainers are interested in doing it to solve an extremely uncommon usecase.

So sorry @wijnen I am going to mark this as wontfix and as I suggested before, I guess adding a line in your installation instructions asking users to set an environmental variable is the best solution (compromise).

Having said that if you can come up with a portable solution without any additional overhead and willing to maintain it then do send us a pull request and I will be happy to merge it.

[wijnen]

I am going to mark this as wontfix

I'm disappointed by that, but I understand it.

However:

This solution is not portable.

This is not true. The executable file itself is not portable. This is exactly the problem that autoconf solves: it can create this non-portable file from a portable template. Automake can install it in the proper non-portable location, from a portable Makefile.am.

Having said that if you can come up with a portable solution and willing to maintain it

I'll write the autotools solution I'm thinking of. It's really simple and I am willing to maintain it. The only problem is: it's useless if I'm the only one using it. It needs to be the standard way of installing arduino-mk for people who make releases of their code.

without any additional overhead

This is impossible. As long as different platforms are different, there will always be overhead. I just want that overhead to be handled by the code, not by the user.

Also:

an extremely uncommon usecase

Nobody is going to do something that isn't supported by the code. When making proper releases is possible, I expect it to be more common.

[ivankravets]

Guys, if you want to use single project's configuration for different embedded platforms and build it different operation systems without Git or Make dependencies – try PlatformIO.

P.S: @sudar, thanks a lot for your job. I've played with your make-based tool earlier. Good reminiscences!

[sudar]

Guys, if you want to use single project's configuration for different embedded platforms and build it different operation systems without Git or Make dependencies – try PlatformIO.

Thanks for mentioning this. Will try it out.

P.S: @sudar, thanks a lot for your job. I've played with your make-based tool earlier. Good reminiscences!

Thanks. But the full credit goes to lot of other contributors as well who help me to maintain this project.