A simple way to make the Makefile do the right thing on Linux as well. Similar thing could be done for OSX but I have no way to test.
Makefile: use scons when compiling on a linux host
Have you checked this on Windows too ?
No, I have not touched a windows machine in years and I haven't owned one for more than ten years. It shouldn't change anything for windows, I believe. Would be good to have this tested on Win and MacOSX.
I don't understand why I am not receiving any notifaction mails from github. Strange...
I'm gonna test it this evening If I find the time.
@leggewie I just tested and the proposed syntax does not work on Windows (with nmake).
That being said, I have no problem to merge this if:
Would that be okay ?
Let's fix this properly is what I would suggest. When you say "does not work", what exactly fails and how?
I've always been surprised you are not using scons on windows. Isn't that supposed to work there as well?
@leggewie nmake and make do not use the exact same format for Makefile, hence the suggestion to completely separate those two.
The Makefile for Windows is more a commodity than anything else : it's merely a reminder of the commands one has to type to compile from the terminal. Ideally this would be used by a Windows build machine, but I never could find time to setup one.
Regarding SCons on Windows... that was initially the case. I switched to Projects and Solutions because :
I know SCons can generate Visual Studio solutions, but the resulting solution/project files are weird : they are just a wrapper that calls SCons under the hood from within Visual Studio. I was never fully satisfied with the result.
All that being said, I suppose I could give SCons on Windows another go someday (I miss my perfect dependency tree and the compilation speed it brings). But I don't think it is wise to change that so close to the release.
Does that make sense ?
Thank you for the explanation. I'm happy to consider the release requirements. Honestly, I don't really like the "separation in two files"-copout. That way, a simple "make" still won't do the right thing on either of the boxes.
You say that nmake and make do not use the same format. Do you know where and how they differ? I'm sure there is a way to write syntax to satisfy them both. I wrote the change such that things SHOULD have stayed the same UNLESS uname returned 'linux'. Obviously, it didn't quite work out that way but I still see that as the right approach. Leave things as they are, except if it is detected one way or the other that the build happens on a Linux machine.
@leggewie I was more suggesting to have a Makefile for just *NIX systems in the end.
nmake -f Makefile.windows
I appreciate you willing to make this work on both systems, but I'm not sure it's worth the trouble. I would be happy to drop Windows support for Makefiles if it makes *NIX builds/packaging easier.
well, maybe the best solution is then indeed to "git mv Makefile Makefile.nmake" or "git mv Makefile Makefile.windows". The Makefile was indeed creating a "problem" for the Debian build since that is what the debhelper command would pick up by default.
Alongside that renaming, I suggest to add a README.linux (and possibly README.osx) to indicate at the top-level what people need to do to build the package.
@leggewie Sounds perfect yes !
rename Makefile to Makefile.windows #56
drop any conditional handling and linux-specific code
README: introduce build instructions specific to linux
Ready to merge, I think.
README.linux: slightly improve the wording
@leggewie For your information, I just reorganized the various README files (and moved the content of README.linux into the generic BUILD.md file). I believe things are a bit simpler that way for people to understand.
Let me know if you still think Linux instructions should be in their own files.
That's fine. But I'm confused about the heading levels. You first talk about the third party directory then Debian, then building FreeLAN and then debugging. A restructuring is in order here, I believe.
What is a first, second and third-level heading in your format? I think it's =, - and ### respectively. Is it? That's kind of confusing. Maybe you can also do with just two levels?
== is for top-level header, -- for second-level and the next levels are just ###, ####, and so on. That's standard Markdown.
I'm not sure to understand exactly what you find confusing though: the Debian section is a sub-section of the "Third-parties" one because there is a specific way of installing those third-parties on Debian.
The same goes for the Windows and Debugging sections which are sub-sections of the Building one because they give more specific details on the topic.
I've never seen it before. I certainly do find it odd that the first two levels are below the header-text and third-level and below not only significantly switches the marker but also starts to put it in the front of the text. Is this really used anywhere else but github.com?
Besides, underlining with = for first-level header and - for second-level and then switching to four # for the third-level does not seem to be Markdown. Markdown starts with a single hash and adds one for each level. That is easy to comprehend.
On that topic, I think I noticed your files usually have only one first-level header, don't they? You basically use that as some kind of executive summary of what to find in the file. Or am I mistaken?
if you agree in principle I'd love to push another branch for your review eventually
@leggewie : I always thought the ====thing was standard Markdown, my bad.
Sure, whatever changes/improvements you want to suggest, feel free to do so !
= Header 1 =
== Header2 ==
etc. certainly is standard (mediawiki comes to mind), but mixing underlining and prepending with =, - and # was too much for my little brain to grok. ;-) I'll create a new branch.
@leggewie Haha. I know the feeling : sometimes little things are really annoying. ;)
Thanks for your interest ! I really appreciate it.
I'm working hard on my side to finish all the tasks for the 2.0 release so that we can move forward the packaging phase soon !
Well, you certainly don't want me to mess up with big changes right off the bat ;-)
@leggewie I actually don't care much about who does what. As a long as a contribution is meaningful and can be of use to others, I will happilly consider it, no matter its size.