• Verbosity levels:
  - [x] We need at least one more verbosity level, 'Debug' (or 'test') which contains logging that is a bit exaggerate in verbosity for the usual user. This would be used by tests comparing against a baseline. The users will benefit of this too when opening issues and sending this mostly detailed log to us.
  - [x] Also, implement a comparison operator for these levels, so that one level may include another.

• Audit all printed messages for their proper verbosity level and display channel (some need to be bumped up to notification popups besides simple logging)

Some things to think through, about build log, dryrun cache and what they mean together in the Makefile Tools ecosystem.

Build log

• for now it is thought as a file path provided by the user, who has the responsibility to point to a valid and useful build log produced outside the extension
• I can see the value of having a build log saved automatically by the extension, when it has no failures
• how about saving the build log also when it fails, while keeping a last known good one available

Dryrun cache

• for now, it is thought as a file generated by the extension whenever other settings don't prevent an invocation of make with --dry-run switch. When a dryrun cache is seen as available (via the path setting), make --dry-run is not invoked anymore. A --dry-run is invoked again (saving a new cache) when the watchers detect relevant changes have been made in settings or in makefiles.
• I realize we might want to invoke a dry-run even if there is already a cache detected, if that dryrun failed

Both of them:

• how about including the configuration and target into the name of these files, so that the extension is able to save more versions of the files instead of overriding their content
• a build or dryrun with errors may still be useful, depending on how much it failed. I'm thinking to always save the last ones, regardless of their success, but also keep a last known good.
• currently, when both defined, buildLog has priority because I thought it's something provided by the user (and it's never generated, re-generated or copied by the extension). But I see value in merging the two settings. The extension to generate many buildLog_config_target.log and dryrunCache_config_target.log from which the user can choose into one setting. Or have buildLog and dryrunCache still separated, but buildLog being generated and re-generated by the extension (as opposed to now when it's not) to separate make and make dry-run outcomes.

If we go the multiple build and dryrun logs route, using the $ syntax or commands () to automatically include configuration and target in the file names would be nice.
#25

If the current makefile configuration fails to a degree that is not able to produce even the targets (this means IntelliSense is gone also) and if that configuration would be actually able to succeed if one particular target would be passed to make (and the user knows it), currently with an empty quick pick the user can't exit from a failure state in the extension (unless defining a new makefile configuration with all the properties of the current makefile configuration and as an argument the extra target).

I'm thinking to make the quick pick editable for such cases.

This is not needed for makefile.buildConfiguration, which comes entirely from the user.
This is not needed for launch configurations (even if they are also a quick pick populated by a dry-run) because their computation would already benefit of the good target being already selected.

I wasn't able to put this in 'triage' and is already placed in 'to do'.

See #45 for the repro setup.

With that repro, the KBUILD_BASENAME is reported as being KBUILD_BASENAME= instead of something like KBUILD_BASENAME="alarmtimer"

IntelliSense stopped working without any change into the Makefile Tools repo but after a few months break.
Suspecting something out of date. Tuning versions in package.json.
Also, very important, update the CppTools from 2.1.2 to 4.0.1 (2 new small APIs to implement).
Additionally, bring IntelliSense modes and C/CPP Standards up to date with the newest values and deduction logic, in sync with CppTools and CMake Tools, for a better IntelliSense user experience.

I believe this is already complete, but adding a task to ensure that we're done with this.

Functionality is dependent on dry run succeeding.

We need to get the 3rd party notices generated and added to the repo. Please talk with Sean about it as he set it up for cpptools.

I did this repro on Linux Ubuntu 20 via WSL2, but it probably repros on other OS's if you can install all the necessary build tools.

'git clone https://github.com/raspberrypi/linux' and checkout branch rpi-4.19.y.

Get the Makefile: Build the target ALL to work. You may need to install a bunch of dependencies (the build errors will usually hint at what needs to be installed). You'll also need to run a command to generate a .config file (with no name to the left of the ".") (the output messages will give info on this).

Open linux/kernel/time/alarmtimer.c

Bug: The following lines appear in the build logging, but the forced includes are not being passed to IntelliSense, which appears to be causing a "No IL" message on hover.

-include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h

Isn't it too long? Also, I thought it would be a short clear correspondent of the CMake commands, which don't have the word tools in them. I was thinking "Make." is short but also clear. I have no problem renaming to "Makefile." though

Since there is no enforcement of unique settings section names, I'm wondering if this should be called makefile. or makefiletools. instead of make. I don't see any other extensions in the marketplace right now so there shouldn't be any conflicts, but you never know...

Originally posted by @bobbrow in #1

Overview

My project uses a Makefile that specifies a lot of system/library headers as target dependencies (see sample output from targets.log):

exmpllogic_bestdataproviderdb.linux.o: ... /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/atomic_base.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/atomic_lockfree_defines.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/basic_ios.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/basic_ios.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/basic_string.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/basic_string.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/char_traits.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/codecvt.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/concept_check.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/cpp_type_traits.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/cxxabi_forced.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/cxxabi_init_exception.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/enable_special_members.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/exception.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/exception_defines.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/exception_ptr.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/functexcept.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/functional_hash.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/hash_bytes.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/hashtable.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/hashtable_policy.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/invoke.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/ios_base.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/istream.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_classes.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_classes.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_conv.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_facets.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_facets.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_facets_nonio.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/locale_facets_nonio.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/localefwd.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/memoryfwd.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/move.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/nested_exception.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/node_handle.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/ostream.tcc /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/ostream_insert.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/postypes.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/predefined_ops.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/ptr_traits.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/quoted_string.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/range_access.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/refwrap.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/shared_ptr.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/shared_ptr_atomic.h /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/shared_ptr_base.h ...
#  Implicit rule search has not been done.
#  Modification time never checked.
#  File has not been updated.

This leads to the extension creating a huge number of targets - making it difficult to find the targets that users are expected to use.

Expected Behaviour

Ideally, I'd like to only see a small subset of targets that are commonly used, for example: clean/build/install/all. In my case, this could possibly be generated from PHONY targets, but I unsure whether this applies to all Makefile projects.

Actual Behaviour

Every system/library/app header and object is listed as a target.

A few seconds after startup. Repro project is as described at #45 .

mainThreadExtensionService.ts:65 [[object Object]]Cannot read property 'trimLeft' of undefined
$onExtensionRuntimeError @ host.ts:10
_doInvokeHandler @ rpcProtocol.ts:372
_invokeHandler @ rpcProtocol.ts:372
_receiveRequest @ rpcProtocol.ts:253
_receiveOneMessage @ rpcProtocol.ts:185
(anonymous) @ rpcProtocol.ts:51
fire @ event.ts:584
fire @ ipc.net.ts:459
_receiveMessage @ ipc.net.ts:792
(anonymous) @ ipc.net.ts:647
fire @ event.ts:584
acceptChunk @ ipc.net.ts:216
(anonymous) @ ipc.net.ts:137
t @ ipc.net.ts:859
emit @ events.js:223
addChunk @ _stream_readable.js:309
readableAddChunk @ _stream_readable.js:290
Readable.push @ _stream_readable.js:224
onStreamRead @ internal/stream_base_commons.js:181
mainThreadExtensionService.ts:66 TypeError: Cannot read property 'trimLeft' of undefined

• Users can debug a target
• Users can launch a target
• Users can pass arguments to a target for debug/launch

Reading from the build log or the dryrun cache can be done once, at configure time, parse all that's needed on a parallel thread, ahead of time and have the items available for quick picks when requested (instead of parsing when quick pick is invoked).

The functions for build targets versus launch targets started with having different dry-run switches in mind but now since they are able to share the same input, they could use a rewrite and refactoring of all involved helpers. Remove process handling from them and simplify how they call each other.

Thanks for the invitation to this repository.

I do most of my C coding for scummvm: https://github.com/scummvm/scummvm/.
In my case I want to run ./configure --disable-all-engines --enable-engine=director to only have scummvm build the
part of the program I develop on. This makes the binary smaller by 111 MB that is a 90% size reduction.

I would be great if quick options are available for this. Sometimes I need to run a full build, i.e. ./configure and other times
I need to add an address sanitizer: ./configure --enable-asan.

Many customers prefer having a UI of some sort to interact with. We need to investigate what type of UI would be best for our users. The UI would connect to existing commands/data.

Sync helpers in util need async counterparts.
Also, callers of the sync versions need to be evaluated whether it's best for them to be sync or async.

If we can't do this automatically, we should add a property to the makefile.configurations object for this so that users can focus on the targets that matter to them.

• identify long running tasks
• notify the user if the task they requested is blocked by an already running task
• provide a way to cancel long running tasks

Favor CMake and keep Makefile partially activated.

The CMake Tools extension shows the CMake output window. Otherwise, the user has to manually switch to the Makefile output window to see important error or logging information.

Similar to CMake Tools, create an outline of the targets and how the source files relate to them. This view could have additional features like: shortcuts to build a target, compile a specific file, debug/launch a target.

Implement variables and expansion mechanism to make the settings more configure-able.
Example: buildLog to be defined as build_${configuration}${target}.log
or dryrunCache${command:makefile.buildConfiguration}_${command:makefile.buildTarget}.log if we implement the commands.

Overview

My project uses Red Hat's DTS in order to build. This means that some include directories are implicit:

$ cpp -v /dev/null -o /dev/null
Using built-in specs.
Target: x86_64-redhat-linux
...
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 
...
#include "..." search starts here:
#include <...> search starts here:
 /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include
 /usr/local/include
 /opt/rh/devtoolset-7/root/usr/include
 /usr/include
End of search list.
...

Judging by this StackOverflow, it appears to be a common thing with GCC.

Due to the above, my Makefile does not explicitly specify the system include directories. This misleads the extension to ignore the system include paths (see excerpt from configurationCache.log):

                        "includePath": [
                            "/workarea/exmpllogic",
                            "/opt/bb/include/"
                        ],

As a result, autocompletion/syntax checking breaks on system includes:

Expected behaviour

System includes are detected by the extension and are automatically picked up by auto-complete/syntax checking. This mirrors the behaviour of what I see today with CMake Tools extension.

Actual behaviour

System includes aren't detected by the extension and the user has to manually specify -I/usr/local/include -I/usr/include ... for auto-complete/syntax checking to work correctly.

Validate for types and structure (missing or unknown) for all properties of the objects defined in settings.

• Users can build all targets described by the Makefile
• Users can build 'clean' (if the target exists)
• Users can build a specific target
• Support pre-configure scripts for building
• Selecting a target allows for filtering as you type (I think we get this for free from VS Code)
• Users can rebuild all (== clean + all)
• Users can rebuild a specific target (== clean + target)

Read miMode and miDebuggerPath from settings first and if provided bypass the guessing logic.
Tweak the guess logic in sync with latest CMake Tools.

makefile.configurations: [ {}, ... ]
makefile.loggingLevel: string
makefile.makePath: string
makefile.makefilePath: string
makefile.dryRunSwitches: [ "--always-make", "--keep-going", "--print-database" ]
makefile.launchConfigurations: [ {}, ... ] similar with cmake.debugConfig, but associated to a particular binary and arguments
miMode, miDebuggerPath, stopAtEntry and symbolsSearchPath also available as general settings besides within the launch configuration object

Also this item covers the work to move some settings into state: current build configuration, current target, current launch configuration.

Configuring from cache is in general fast but for large projects it's still not instantaneous and when verbose logging is enabled is can last a while. Make this functionality truly async as well.

Example: arm-linux-gnueabihf-gcc

"But, I do think that if you encounter a string that matches the pattern \S*-gcc or \S*-ld, I think it is relatively safe to assume that that string refers to a compiler or linker, respectively. If you want to be even more sure, you could check the output of my-special-compiler-gcc --version and see determine if it is a compiler that way. Just an idea."

• show configure/build options in the context menu when right clicking on a Makefile in the file explorer
• show configure/build options in the context menu when right clicking in the active editor

The exit codes for configuration are being merged into a single value which doesn't help us understand whether the process is succeeding or failing. We need to either send separate messages for each sub-step, or send the data for the sub-steps as individual properties in the configure event.

Add a property to makefile.configurations objects for problem matcher support. (e.g. $gcc, $msbuild)

1. Activate if Makefile is found in the root folder
2. Activate if any makefile.* command is invoked

• makefile.configure
• makefile.setBuildConfiguration
• makefile.buildAll
• makefile.buildTarget
• makefile.setBuildTarget
• makefile.rebuildAll
• makefile.rebuildTarget
• makefile.debug
• makefile.launch
• makefile.setLaunchTarget

Review all the globals and their access.
Use getters/setters when working with them in their own file (they are already used when other files access them).
Evaluate whether some need more encapsulation.

Here is some additional feedback: in large projects like this, it is common for not all source files to be compiled. With this extension, if a source file is not compiled, then there is no configuration for it, so IntelliSense will likely give all sorts of #include errors. It would be nice if there was a way to provide a non-intrusive warning to the user when they open a file for which there is no configuration for. I do see that there is a message in the output log that looks like "Configuration for file /.../.../... was not found. CppTools will set a default configuration." So perhaps whatever branch in the code prints this message could also be used to provide this warning. Unfortunately though, it might not be this simple. When I open a header file that was #include'ed during the kernel build, this same message also gets printed to the output log. This makes sense, as header files don't get passed to the compiler as a source file, so this extension doesn't know about them.

Maybe it would be possible to generate a list of dependencies for each source file during the configuration process, and then not warn when opening one of these dependencies? This could be done as follows (I'll use the source file fec_main.c in my project as an example.)

fec_main.c gets compiled with this enormous command:

arm-linux-gnueabihf-gcc -Wp,-MD,drivers/net/ethernet/freescale/.fec_main.o.d -nostdinc
-isystem /usr/lib/gcc-cross/arm-linux-gnueabihf/7/include -I./arch/arm/include
-Iarch/arm/include/generated/uapi -Iarch/arm/include/generated
-Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian
-fdebug-prefix-map==. -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE
-fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra
-mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a
-msoft-float -Uarm -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -fdebug-prefix-map==.
-D__CHECK_ENDIAN__ -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fec_main)"
-D"KBUILD_MODNAME=KBUILD_STR(fec)" -c -o drivers/net/ethernet/freescale/.tmp_fec_main.o
drivers/net/ethernet/freescale/fec_main.c

This command builds the object file and creates a dependency file at ".fec_main.o.d". But when building the kernel, this dependency file is deleted towards the end of the build process. Even if this dependency file was not deleted, it would not be good to rely upon its existence because not all build systems will generate these dependency files. To generate this dependency file, I'd recommend the following procedure:

1. Remove all "-M*" options from the gcc command. See https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html and Ctrl+F for "-M" to see the various -M* options. (The command above does not have a -M* parameter directly, but it could in general. The command above instead uses the -Wp option; see the next step in this procedure.)
2. If the gcc command contains a "-Wp" option (like the command above does), search within this string for the same "-M*" options and remove them. -Wp is used to pass options directly to the pre-processor. If there are no options remaining in the comma-separated list after -Wp, then the -Wp option must be removed entirely. (You can't use -Wp with an empty list of options. On my system, just using "-Wp" is an error, and "-Wp," causes gcc to hang.)
3. Remove the -o option from the gcc command, if one exists.
4. Add "-M" to the gcc parameters.
5. Run the resulting command, and the dependencies should be output to stdout. The extension could capture this output, or direct it to a file using the "-MF my_dependencies.d" option after the "-M" option from step 4.
   Any files that appear in this dependency list should not cause a warning when opened.

Here is the resulting command after following the above procedure:

arm-linux-gnueabihf-gcc -M -nostdinc
-isystem /usr/lib/gcc-cross/arm-linux-gnueabihf/7/include -I./arch/arm/include
-Iarch/arm/include/generated/uapi -Iarch/arm/include/generated
-Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian
-fdebug-prefix-map==. -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE
-fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra
-mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a
-msoft-float -Uarm -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -fdebug-prefix-map==.
-D__CHECK_ENDIAN__ -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fec_main)"
-D"KBUILD_MODNAME=KBUILD_STR(fec)" -c
drivers/net/ethernet/freescale/fec_main.c

See the screenshot:

It should be something like

Configuring: Parsing for launch targets (inspecting for link commands)...

in which "..." don't occur in the middle of the message, and the ( has a matching ).

• configure
  • success/failure
  • first try success?
  • elapsed time
  • # of targets
  • cpptools integration prompt accepted? (needs to go into cpptools)
  • active configuration changed
• build
  • success/failure
  • build all vs build target
  • build target changed
  • clean
• debug
  • session started (success/failure)
  • debug target changed
• settings changes
  • configurations changed

To be able to make the extension work also in a neutral environment, implement kits same as CMake Tools does.

Overview

My binary requires some CLI arguments in order to start. Typically, for other languages and for CMake C/C++ projects, I'd put my arguments into launch.json.

Expected Behaviour

Ideally, I could make use of launch.json in a very similar fashion to CMake extension:

"program": "${command:cmake.launchTargetPath}"

Actual Behaviour

Launch/debug targets appear to be configured separately via makefile.launchConfigurations.

For preview 1, we are fixing #8 by adding a new setting (list only phony targets defaulting to false) and by printing only the targets that were manually marked ".PHONY" by the developer.
In future it would be nice to include in that fix a more advanced analysis of how phony is a target that was not defined so by the user. Like evaluate if the target name represents a file on disk or not.

Phony definition:
A phony target is one that is not really the name of a file; rather it is just a name for a recipe to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance.

When generating the targets list, we are saving the log to disk. This log is huge and we should have this data available already anyway once you finish the caching work.

• Add a makefile.configurations setting in package.json which documents all the available sub-properties.
  • name: string
  • makePath?: string - path to make, use makefile.makePath if not specified
  • makeArgs?: string[] - args to pass to make
  • makefilePath?: string - path to makefile, use makefile.makefilePath if not specified
• Add a way to manage/select the active configuration
• Add file watchers to track changes to makefile
  • auto-reconfigure when focus changes
  • Add a setting to disable this
• Cache the dry-run output. Refresh when watchers indicate so.
• Errors are communicated to the user
  • dry-run failures -> link to GitHub issues page so customer can open an issue
  • if project requires special flags, point them to makefile.configurations setting (perhaps via documentation)

We should change the default location for logs that we persist to disk and allow users to override the default value. We should probably default to the "storagePath" VS Code provides when extensions are activated.

vscode.ExtensionContext.storagePath:

We need to set up a CG pipeline for this repo. Please talk with Sean about what is required.

Clean configure = replace the internal IntelliSense configurations
(non-clean) configure = replace the changed IntelliSense configurations (leave unchanged ones alone)

Configure on open does a "clean" dryrun, but we can use existing configurations while we wait for that to complete.

Similar to CMake Tools. The extension should activate if the Makefile is found anywhere in the workspace. The user should be prompted to locate the Makefile if the appropriate setting is not set. The extension will be partially activated until the setting is set.